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

Versions: 00                                                            
Internet Engineering Task Force                                      Editors
INTERNET DRAFT                                      Partha Bhattacharya, IBM
                                                              Rob Adams, Cisco
                                                      William Dixon, Microsoft
                                                         Roy Pereira, Timestep
                                                                Raju Rajan, IBM


                                                                October 9 1998
    An LDAP Schema for Configuration and Administration of IPSec based
                       Virtual Private Networks (VPNs)
                    draft-ipsec-vpn-policy-schema-00.txt


    Status of 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 learn the current status of any Internet-Draft, please
       check the
       ``1id-abstracts.txt'' listing contained in the
       Internet-Drafts Shadow Directories on ftp.ietf.org (US
       East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West
       Coast), or munnari.oz.au (Pacific Rim).


    Abstract


       This document describes the structure of an LDAP directory
       schema that enables policy based configuration and
       administration of IPSec based Virtual private networks
       within and among Internet domains, intranets, and extranets.
       The schema extends the base IPSec Policy data model in [9]
       to include end hosts and security gateways.  The schema
       closely follows and expands on the DEN specification [7].
Bhattacharya et.  al.              Expires April 9 1999             [Page i]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

1.  Introduction


    IPSec [1], [2], [4] is a fairly large and complex protocol requiring
    participating hosts to negotiate a number of configuration parameters
    during protocol operation.  These parameters typically have security
    related implications, so that defaults specified in the IPSec
    documents may not be acceptable to certain end hosts.  In such
    cases, IPSec negotiations would fail and manual intervention would
    be required.  Furthermore, the defaults may lead to redundancies
    in situations where the end hosts are also performing security
    operations at a higher layer (e.g.  SSL).


    The situation becomes more complex if security gateways have to be
    traversed for two end hosts to communicate.  Depending on the end
    host application, a gateway may either deny or permit the connection
    or require an IPSec tunnel from either the end host or another
    gateway acting as a IPSec proxy for the end host.  For successful
    communication, the gateways have to be properly configured to
    establish IPSec tunnels with certain end hosts and gateways.


    In the light of the above discussion, it is plausible that manual
    configuration of each IPSec host will become less and less viable
    as more hosts become IPSec enabled.  Directory based policy
    administration is becoming increasingly popular as a versatile and
    uniform means of managing network services.  LDAP [3] is a widely
    deployed industry standard for accessing directory information.  This
    document presents an LDAP schema for storing IPSec based policy
    information in a central directory.  The schema describes


    - the required IP layer security attributes of a connection; i.e.
    whether the connection should be blocked, permitted in the clear or
    secured by IPSec,


    - end to end IPSec security association attributes in case the
    connection needs to be secured by IPSec,


    - whether security gateways need to be traversed using IPSec; and if
    so, then the gateway address and the corresponding IPSec security
    association attributes,


    - nested gateway traversal, etc.


    We allow policies to be specified for groups of hosts by either
    specifying groups or ranges of addresses or wildcarded domains.
    Policies can also be specified by specific user ids as required by
    IPSec.


    The rest of the document is as follows.  Section 2 provides general
    ideas of representing policy rules through a Policy object, the
    overview of the LDAP schema and the various object classes and their
Bhattacharya et.  al.             Expires April 9 1999             [Page ii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

    inter-relationships.  The schema described above closely follows the
    policy class hierarchy described in the DEN document [7].  Sections
    3-7 details the various objects and their attributes.  Section 8
    concludes with some VPN scenarios and examples.

1.1.   Specification of Requirements

    The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
    and "MAY" that appear in this document are to be interpreted as
    described in [Bradner97].

2.  Class Hierarchy

    In this section, we describe the various classes related to Policy
    definition, their inheritance hierarchy and inter-relationships.
    They are best understood within the Common Information Model [8]
    of the Directory Management Task Force or the directory structure
    proposed by the Directory Enabled Networks (DEN) specification [7].

                     Top
                    |----Policy
                    |
                    |----PolicyCondition
                    |      |
                    |      |--IPPolicyCondition
                    |
                    |-----UserIDCondition
                    |
                    |----PolicyValidityPeriod
                    |
                    |----PolicyAction
                    |       |----RSVPAction
                    |       |----DiffServAction
                    |       |----ISAKMPAction
                    |       |----IPSecSecurityAction
                    |
                    |----DiffServResourceGroup
                    |----RSVPResourceGroup
                    |----ISAKMPProposal
                    |----IPSecProposal
                    |----IPSecTransform
                    |----IPSecPrivateDiffieHellmanGroup
                    |
                    |----PolicyContainmentAuxClass

    The schema described here closely follows the policy class hierarchy
    described in the current DEN document [7].  This document expands on
Bhattacharya et.  al.            Expires April 9 1999             [Page iii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

    the DEN specification but differs in a few significant details, where
    it was felt that the specification tended to be unclear or redundant.


    A structural LDAP object class called Policy is defined as the
    container for policy rules.  An object of this class ``pieces
    together'' several policy components relating to differentiated
    services, RSVP and IPSec based VPNs.  Only the IPSec related
    parameters are described here; the RSVP and differentiated services
    related parameters are described in a related document [6].


    A Policy rule is encoded as


          if <PolicyCondition>  then <PolicyAction>


    A PolicyCondition class specifies attributes that determine
    when a policy rule applies.  These include validity time related
    parameters and traffic descriptors such as ranges of IP packet
    header attributes, MAC addresses etc.  The policy validity time
    is described by reference to a PolicyValidityPeriod object that
    specifies conditions restricting the validity period of a policy
    rule.


    IPPolicyCondition is a subclass of PolicyCondition and describes
    the conditions based on IP packet header attributes.  The reason
    for subclassing PolicyCondition is to allow extensibility to other
    networking protocols through sub-classes.  Sometimes an IPSec policy
    needs to be specified by specifiying host or user ids.  This is
    allowed by a reference to a UserIDCondition class that describes a
    set of ids such as Host FQDN, User FQDN, X.500 name etc.


    A PolicyAction class specifies a collection of attributes that detail
    permissions or additional behaviors that the policy enforcement
    entity MUST perform when the corresponding policy condition is
    satisfied.  The PolicyAction class is subclassed into a number
    of protocol or service specific actions -- DiffServAction,
    RSVPAction, ISAKMPAction and IPSecSecurityAction.  The QoS related
    classes:  DiffServAction, RSVPAction, DiffServResourceGroup and
    RSVPResourceGroup are defined in a related document [6].  This
    document focuses on the IPSec related classes ISAKMPAction and
    IPSecSecurityAction.


    The ISAKMPAction class specifies attributes required to perform
    an ISAKMP/Oakley Phase 1 exchange.  These include exchange mode,
    authentication types, Phase 1 proposals, Phase 1 connection
    management parameters etc.  The proposals are described by references
    to ISAKMPProposal objects.  If Private Diffie Hellman groups are to
    be used in the proposal then an ISAKMPProposal object must contain
    references to IPSecPrivateDiffieHellmanGroup objects describing
    private Diffie Hellman groups.


Bhattacharya et.  al.             Expires April 9 1999             [Page iv]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

    The IPSecSecurityAction class specifies the security action (e.g.
    permit/deny/secure) for a traffic stream.  If the traffic is to be
    secured by IPSec, then this class specifies attributes required for
    ISAKMP Phase 2 (or Quick Mode) exchange.  These include proxy ids,
    Phase 2 proposals, and Phase 2 connection management parameters.
    The Phase 2 proposals are described by references to IPSecProposal
    objects.  An IPSec Proposal consists of logically AND-ed combinations
    of AH, ESP and IPCOMP protocols.  The transform attributes for each
    protocol are described by references to corresponding IPSecTransform
    objects.


    The modular object design is done to promote the sharing of objects
    such as IPSecTransforms, IPSecProposals and ISAKMPProposals.


    Finally, given a device identity, it must be possible to find
    all the policies applicable for that device.  The auxiliary class
    PolicyContainmentAuxClass as defined in the DEN specification [7] is
    for that purpose.  It can be attached to a variety of classes that
    describe devices.  The PolicyContainmentAuxClass itself contains
    an attribute PoliciesContainedRef describing a list of related
    policies.  Therefore the policies for a given device can be obtained
    by retrieving all the objects specified by the PoliciesContainedRef
    attribute in an appropriate class such Device (or any other class to
    which the PolicyContainmentAuxClass class is attached).

3.  The class Policy

    The Policy object class is the container class for the policy rules.
    It contains a number of entries, each entry encodes a policy rule
    that specifies the resources and services that are allowed (or
    denied) to a stream of packets.  An overview of the class Policy is
    presented below, followed by the detailed sytax and semantics of
    various attributes.


NAME              Policy
TYPE              Structural
DERIVED FROM      Top
MUST
                  CommonName,
                  PolicyScope,
                  PolicyConditionRef,
                  PolicyActionRef,
                  PolicyVersion
MAY
                  PolicyRulePriority,
                  PolicyKeyword,
                  PolicyType,
                  PolicyName,
                  PolicyEnabled
Bhattacharya et.  al.              Expires April 9 1999             [Page v]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

    The syntax and semantics of the attributes of the class Policy are as
    follows:


NAME      CommonName
DESC      The common name for objects of this class. Used as relative
          distinguished name to identify object within a branch of
          directory tree.
SYNTAX    IA5String
EQUALITY  caseExactIA5Match
SINGLE-VALUED


NAME       PolicyScope
DESC       Lists the services that are controlled through this policy
EQUALITY  caseExactIA5Match
SYNTAX      IA5String
MULTI-VALUED
FORMAT:    The currently defined values for this attribute are:
           DiffServ
           RSVP
           IPSec
           ISAKMP
SEMANTICS: This attribute is used by the appropriate directory clients
           to fetch only those policy rules that are relevant for their
           functionality. The value  DiffServ' means the policy rule
           specifies DiffServ packet classification and traffic treatment.
           The value `RSVP' means specifes an RSVP policy
           decision point. The value `IPSec' means the policy refers
           to an IPSec action rule. The value `ISAKMP' means the policy
           refers to an ISAKMP action rule. Note that this is a multi-
           valued attribute, and the same rule may regulate multiple
           services for a packet stream.


NAME    PolicyConditionRef
DESC    Absolute Distinguished name of LDAP entry of the objectclass
        PolicyCondition, that identify the packets that the policy rule
        applies to.
EQUALITY distinguishedNameMatch
SYNTAX  DN
SINGLE-VALUED


    The following reference attributes specify the treatment of packets
    that match the condition specified in the policy rule.  The value
    of a reference attribute is the distinguished name of an LDAP entry
    which is an object corresponding to a prespecified class.  For
    instance, if the value of the attribute PolicyActionRef is the
    distinguished name of an entry in the class RSVPAction, then the
    policy rule specifies the policy relating to the handling of RSVP
    signalling messages.


NAME      PolicyActionRef
Bhattacharya et. al.             Expires April 9 1999              [Page vi]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

DESC      Absolute Distinguished name(s) of LDAP entry, of the objectclass
          PolicyAction, that specifies permissions and restrictions
          that apply to the packets identified by the policy condition
EQUALITY distinguishedNameMatch
SYNTAX     DN
MULTI-VALUED
SEMANTICS Multiple values are understood as logical AND; that is, all
           the actions must be performed
NAME      PolicyVersion
DESC      The version of the policy schema embodied by this policy.
SYNTAX    IA5String
FORMAT    The current draft specifies version ``1.0''
EQUALITY  caseExactIA5Match
SINGLE-VALUED
NAME      PolicyKeyword
DESC      List of keywords that assist in locating this policy
SYNTAX    IA5String
MULTI-VALUED
DEFAULT  No Keywords


NAME      PolicyType
DESC      Describes the types of a policy
SYNTAX    IA5String
MULTI-VALUED
FORMAT    The following values are allowed:
              ISAKMPPhase1
              ISAKMPPhase2
              IPSecDataLocal
              IPSecDataRemote
              RSVPSignalling
              RSVP-DiffServ
              DiffServ


SEMANTICS ISAKMPPhase1 denotes an ISAKMP Phase 1 policy
           ISAKMPPhase2 denotes an ISAKMP Phase 2 or Quick Mode policy
           IPSecDataLocal denotes a policy for securing locally
              originating data by IPSec. Local means either originating
              from the same host or from an host for which this host
              acts as a proxy
           IPSecDataRemote denotes a policy for securing remotely
              originating data by IPSec. Remote is the opposite of Local
              as defined before.
           RSVPSignalling denotes an RSVP signalling policy
           RSVP-DiffServ denotes a policy for mapping an RSVP traffic
              into a DiffServ pipe
           DiffServ denotes a DiffServ policy
Bhattacharya et. al.            Expires April 9 1999              [Page vii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

DEFAULT  Unnamed Type


NAME       PolicyName
DESC       A user friendly name of this policy class
SYNTAX     IA5String
SINGLE-VALUED
DEFAULT    No Name


    The following attribute defines relationships among multiple related
    rules within the policy repository.


NAME     PolicyRulePriority
DESC     Priority level for this rule. Used to resolve ambiguity in
         condition matching when the ranges specified in the Policy
         conditions overlap. Higher values of this attribute imply
         higher priority of the rule.
EQUALITY integerMatch
SYNTAX    INTEGER
DEFAULT  The default value is 0 (lowest priority)
SINGLE-VALUED
SEMANTICS: Whenever a packet matches two rules of different priority,
           the rule with the higher value of PolicyRulePriority is
           applied.


NAME  PolicyEnabled
DESC  A flag describing whether the policy is currently enabled or
       disabled
SYNTAX  IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT  The currently defined values for this attribute are:
    Enabled
    Disabled
DEFAULT Enabled

3.1.  PolicyContainmentAuxClass


    Policy rules may need to be grouped together for a number
    of different purposes -- organizational, security, ease of
    administration, or ease of retrieval by a policy decision point.  We
    reproduce the PolicyContainmentAuxClass from the DEN specification
    [7] that serves the useful purpose of grouping policies together.
    This auxillary class definition is as follows:

NAME                    PolicyContainmentAuxClass
TYPE                    Auxillary
DERIVED FROM           Top
AUXILIARY CLASS        None
POSSIBLE SUPERIORS     Organization, OrganizationalUnit, Group,
Bhattacharya et. al.            Expires April 9 1999             [Page viii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

                         GroupOfDevices
MUST                    PoliciesContainedRef
MAY


    The syntax and semantics of its sole attribute are as follows:


NAME     PoliciesContainedRef
DESC     Absolute distinguished names of policies grouped together
         for some (context-dependent) purpose.
SYNTAX  DN
EQUALITY distinguishedNameMatch
MULTI-VALUED

4.  Policy Conditions

    In this section we define the abstract class PolicyCondition, its
    subclass IPPolicyCondition, and the class UserIDCondition.  These
    classes list the conditions that must be statisfied by a stream of
    packets in order for the referring rule to apply to that packet
    stream.


    The reason for subclassing PolicyCondition is to allow extensibility
    to other networking protocols through sub-classes such as
    ATMPolicyCondition (for instance).


NAME                    PolicyCondition
TYPE                    Abstract
DERIVED FROM           Top
AUXILIARY CLASS        None
MUST                    CommonName
MAY                     PolicyConditionName
                         PolicyValidityPeriodRef


    The detailed syntax and semantics of the attributes is as below:


NAME      CommonName
DESC      The common name of the policy condition object. Unique within a
          limited scope and used to identify the object within the
          directory tree.
SYNTAX    IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED


NAME      PolicyConditionName
DESC      The user friendly name of this entry.The Name related attributes
          are only for ease of user administration.
EQUALITY caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED
Bhattacharya et.  al.             Expires April 9 1999             [Page ix]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

    The next attribute is a reference to PolicyValdityPeriod object that
    identifies the entry that limits the temporal scope of the policy to
    specified periods of time.


NAME      PolicyValidityPeriodRef
DESC      Absolute distinguished name(s) of an PolicyValidityPeriod
          object that specifies the times that the policy is active.
EQUALITY distinguishedNameMatch
MULTI-VALUED
SYNTAX    DN
DEFAULT  Policy applies at all times

4.1.  The class IPPolicyCondition

    The class PolicyCondition is now specialized to deal with IPv4 packet
    headers in the class IPPolicyCondition.


NAME                    IPPolicyCondition
TYPE                    Structural
DERIVED FROM           PolicyCondition
AUXILIARY CLASSES      none
MAY                     Interface,
                         SourceIPAddressRange,
                         DestinationIPAddressRange,
                         SourcePortRange,
                         DestinationPortRange,
                         IPProtocolNumberRange,
                         ReceivedTOSByteCheck
                         HostUserIDRef
    The first attribute limits the spatial scope of the policy rule by
    identifying specific router interfaces where the policy is to be
    applied.


NAME     Interface
DESC     An attribute that limits the scope of the policy to packets on
         specified  interface(s) and the direction(s) of traffic on these.
EQUALITY caseExactIA5Match
SYNTAX  IA5String
MULTI-VALUED
FORMAT  Three colon seperated strings. The left-most string is a numeral
         denoting the type of the specification, followed by the incoming
         and outgoing interface identifiers. Currently defined type/value
         formats are
         1:<IPv4Address>:<IPv4Address>
         2:<InterfaceID>:<InterfaceID>
         The IP addresses are in dotted decimal notation. The interface
         IDs are integers unique to the host device.
Bhattacharya et. al.              Expires April 9 1999              [Page x]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

         The first address string specifies a restriction of the rule
         to traffic inbound on the interface, and the rightmost string
         specifies a corresponding restriction of the rule to traffic
         outbound from that interface.  An unspecified interface(s)
         defaults to all interfaces on the device that this rule
         applies to.


EXAMPLE  1:9.3.1.52:9.2.1.54 (Applies to traffic inbound on 9.3.1.52
                                  and outbound on 9.3.1.54)
           1:9.3.1.32: (Applies to traffic inbound on 9.3.1.52
                          outgoing from any interface)
           2::3         (Applies to traffic outbound on interface 3
                          arriving on any interface)
DEFAULTS  Defaults to traffic inbound on all interfaces, outbound on
           all interfaces.


NAME      SourceIPAddressRange
DESC      Source IP addresses to which the policy applies
EQUALITY caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED
FORMAT    SourceIPAddressRange is of the following form: three colon (':')
          separated strings denoting a range of IP addresses. The
          following formats are currently defined


          1:<IPv4Address>:<CIDRPrefixLength>
                  The IP v4 address is in dotted decimal format. The
                  CIDRPrefixLength is the number of unmasked leading bits.
                  A packet matches the condition if the unmasked
                  bits on the packet are identical to the unmasked bits on the
                  condition.


          2:<IPv4Address>:<IPv4Address>
                  IP addresses in dotted decimal format. The second
                  address must be no smaller than the first. The first
                  denotes the start of the range, and the second denotes
                  the end of the range. A packet matches the condition
                  if its source address is no smaller than the first
                  IP address in the condition, and no larger than the
                  second.


          3
                  Indicates policy applies to locally generated packets.
EXAMPLE       1:83.23.23.1:24
                    A packet with source address 83.23.23.5 matches.
                    A packet with source address 83.23.24.1 does not.
               2:83.23.23.0:83.28.28.0
                    A packet with source address 83.23.23.5 matches.
                    A packet with source address 83.29.24.1 does not.
DEFAULT       Defaults to the entire address range, i.e., every packet
Bhattacharya et. al.             Expires April 9 1999              [Page xi]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

               matches the source address range condition.
NAME       DestinationIPAddressRange
DESC       Destination IP addresses to which policy applies
EQUALITY caseExactIA5Match
SYNTAX     IA5String
SINGLE-VALUED
FORMAT    Identical to that of SourceIPAddressRange above.
          The value of ``3''indicates a locally destined packet.
DEFAULT Defaults to the entire address range, i.e., every packet
         matches the destination address range condition.
NAME      SourcePortRange
DESC      Source Ports to which policy applies
EQUALITY caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED
FORMAT    String consisting of two colon separated positive
          integers, the second no smaller than the first, or one
          positive integer.
DEFAULT  Defaults to the entire port range 0 to 65535, i.e., every
          packet matches the destination address range condition.
EXAMPLE  8000:8080 (ports 8000 to 8080),
          8000 (only port 8000)
NAME      DestinationPortRange
DESC      Destination Ports to which policy applies
EQUALITY caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED
FORMAT    String consisting of two colon separated positive
          integers, the second no smaller than the first, or one
          positive integer.
DEFAULT  Defaults to the entire port range 0 to 65535, i.e., every
          packet matches the source address range condition.


NAME      IPProtocolNumberRange
DESC      Protocol numbers to which policy applies
EQUALITY integerMatch
SYNTAX    INTEGER
SINGLE-VALUED
FORMAT    String consisting of two colon separated positive
          integers, the second no smaller than the first, or one
          positive integer.
DEFAULT    Defaults to the entire protocol range 0 to 255, i.e., every
           packet matches the ip protocol range condition.
EXAMPLE  50:51 (protocol 50 to 51),
Bhattacharya et. al.            Expires April 9 1999              [Page xii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

          50 (only protocol 50)


NAME      ReceivedTOSByteCheck
DESC      A condition attribute used to select traffic based on the
          contents of the TOS byte of the received packet's IP header
EQUALITY caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED
FORMAT    String of the form xxxxxxxx:xxxxxxxx, where each of the
          x's is either 0 or 1.
SEMANTICS Each of the substrings is treated as specifying an 8-bit
          field. The left substring is termed Mask and the right
          substring Match. The TOS byte of the received packet's IP
          header is ANDed with Mask and the result is compared against
          Match. The combination of Mask and Match allows definition of
          TOS byte based conditions where certain bits in the TOS byte
          may be ignored for the purpose of comparison.
EXAMPLE  An incoming packet with TOS byte 11001010 matches the
          condition specified by a value of 00111100:00001000 for
          ReceivedTOSByte.
NAME    UserIDConditionRef
DESC    Absolute Distinguished name(s) of LDAP entry or entries, of
        an UserIDCondition object that identify the user or
        host whose packets that the policy rule applies to.
EQUALITY distinguishedNameMatch
SYNTAX  DN
MULTI-VALUED

4.2.  The Class UserIDCondition

    In many scenarios, for instance an end host IPSec, policy needs to
    be specified for a user or a host ID instead of an IP address.  A
    standard example is a corporate worker connecting from home via an
    ISP. The policy would be specified by Host FQDN, UserFQDN, X500 DN
    etc.  To accomodate this source and destination ids are required.


NAME                    HostUserID
TYPE                    Structural
DERIVED FROM           Top
AUXILIARY CLASS        None
MUST                    CommonName
MAY                     SourceID,
                         DestinationID,
NAME       SourceID
DESC       Source Host Identifier
Bhattacharya et. al.            Expires April 9 1999             [Page xiii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

SYNTAX     IA5String
EQUALITY  caseExact1A5Match
MULTI-VALUED
FORMAT     Two strings , colon (`:') seperated, the first describing the
           ID type and the second the ID value. The valid IdTypes and
           their corresponding values are defined in [Piper98]. These
           include:
               Host-FQDN:<ID>
               User-FQDN:<ID>
               X500-DN:<ID>
               X500-GN:<ID>
               Key-Id:<ID>
DEFAULT    Any ID is considered valid.


NAME       DestinationID
DESC       Destination Host Identifier
SYNTAX     IA5String
EQUALITY  caseExact1A5Match
MULTI-VALUED
DEFAULT    Any ID is considered valid.
FORMAT     Same as Source ID

5.  The class PolicyValidityPeriod

    Objects of this class describe conditions that restrict the validity
    period of the policy rule.  The class definition is as follows:


NAME  PolicyValidityPeriod
TYPE  Structural
DERIVED FROM  Top
AUXILIARY CLASSES  NONE
MUST  CommonName
MAY    PolicyValidityPeriodName,
       PolicyValidityTime,
       PolicyValidityMonthMask,
       PolicyValidityDayOfWeekMask,
       PolicyValidityTimeOfDayRange


    The syntax and semantics of various attributes are as given below


NAME      PolicyValidityPeriodName
DESC      The user friendly name of this entry.
EQUALITY caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED


NAME        PolicyValidityTime
DESC        When this policy is valid
EQUALITY    caseExactIA5Match
Bhattacharya et. al.            Expires April 9 1999              [Page xiv]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

SYNTAX      IA5String
MULTI-VALUED
FORMAT      String(s) of the form yyyymmddhhmmss:yyyymmddhhmmss:<TZ>
SEMANTICS  The first two substrings must be valid times,
            (year-month-date-hour-minute- second) the second larger
            than the first. The last substring is optional and
            describes the time zone.
DEFAULT     If the time zone is omitted then the time is local time at
            the policy decision point. If the attribute itself is absent
            then the policy is always valid.
EXAMPLE     19980121060000:19991231133000:GMT
            (meaning Policy in effect from 6:00 AM on January 21, 1998
            to 1:30 PM on December 31, 1999, Greenwich Mean Time).


NAME      PolicyValidityMonthMask
DESC      Months during which policy is valid
EQUALITY caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED
FORMAT    String denoting a mask of 12 0s and 1s.
SEMANTICS 1's corresponding to months in the January to December
           range when the policy is valid.
EXAMPLE  000111111100  (Valid from April until October)
DEFAULT  111111111111, i.e., valid always


NAME      PolicyValidityDayOfWeekMask
DESC      days during which policy is valid
EQUALITY caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED
FORMAT    String representing a mask of 7 0s and 1s.
SEMANTICS  1's correspond to days in the Monday to Sunday range
            when the policy is valid.
EXAMPLE  1111100        (Valid weekdays)
DEFAULT  1111111, i.e., valid always


NAME      PolicyValidityTimeOfDayRange
DESC      Time(s) of day during which policy is valid
EQUALITY caseExactIA5Match
SYNTAX    IA5String
MULTI-VALUED
FORMAT    String(s) of the form  hhmmss:hhmmss
SEMANTICS  Substrings on either side of the colon must be be valid
            time of day values. If the second string is not larger
            than the first, then a wrap around midnight is assumed.
EXAMPLE  090000:170000        (Policy valid from 9 AM to 5 PM)
DEFAULT  000000:235959

Bhattacharya et.  al.             Expires April 9 1999             [Page xv]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

6.  The class PolicyAction


    While implementing policy within a network device, the
    PolicyCondition helps identify a substream of packets that
    are to be granted access to network resources, in a manner that is
    specified by an instantiation of the class PolicyAction.


    The class definition is as follows.


NAME  PolicyAction
TYPE  Abstract
DERIVED FROM  Top
AUXILIARY CLASSES  NONE
MUST  CommonName


    The PolicyAction is subclassed into a number of protocol or service
    specific actions, each of which is described next.

6.1.  The class ISAKMPAction

    This class describes the ISAKMP/Oakley action attributes for
    the traffic flow as described by the linked IPPolicyCondition or
    AuxIDPolicyCondition object.


NAME  ISAKMPAction
TYPE  Structural
DERIVED FROM PolicyAction
AUXILIARY CLASSES    NONE
DESC  Describes ISAKMP/Oakley Phase 1 actions
MUST  CommonName,
       ISAKMPExchangeMode,
       ISAKMPProposalRef
MAY
       ISAKMPActionName,
       LocalHostPublicKeyInfo,
       RemoteHostPublicKeyInfo,
       MinSecurityAssociationLifetimeSec,
       MinSecurityAssociationLifetimeKBytes,
       ISAKMPConnectionLifetimeSec,
       ISAKMPConnectionKBytes,
       SecurityAssociationRefreshThreshold,
       ISAKMPConnectionAutoStartFlag


NAME  ISAKMPActionName
DESC  The user friendly name of this entry.
EQUALITY  caseExactIA5Match
SYNTAX  IA5String
SINGLE-VALUED


Bhattacharya et.  al.            Expires April 9 1999             [Page xvi]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

    The ISAKMPExchangeMode attribute denotes the ISAKMP/Oakley key
    exchange mode:  main or aggressive.


NAME  ISAKMPExchangeMode
DESC  ISAKMP-Oakley key Exchange mode
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The values can be found in [4]
DEFAULT The value corresponding to Main mode


    The ISAKMPProposalRef attribute describes a set of ordered
    ISAKMP proposals.  Since LDAP does not support ordered lists, the
    ISAKMPProposalRef attribute is defined as a composite string in order
    to be able to capture the relative ordering of the proposals.


NAME  ISAKMPProposalRef
DESC  Ordered list of absolute DNs of ISAKMPProposal objects
EQUALITY  caseExactIA5Match
SYNTAX  IA5String
MULTI-VALUED
FORMAT  The format is `pref:ISAKMPProposalDN' where
         - pref is an integer denoting the relative preference of
           the proposal. Lower number has higher preference.
         - ISAKMPProposalDN denotes the distinguishing name (DN) of an
           ISAKMPProposal object


    The following two attributes describe information about the
    repository of public keys for the source and the destination.  The
    information consists of the type of the public key repository (e.g.
    Secure DNS, Certificate Authority, LDAP-Directory, Inline ISAKMP),
    the host name of the public key repository, and acceptable public key
    certificate encodings.


    These are specified as part of policy so that an IPSec host
    can perform the proper public key operations during an actula
    ISAKMP/Oakley exchange.


NAME  LocalHostPublicKeyInfo
DESC  Information about local hosts's public key. Required for public
       key based Authentication in ISAKMP
EQUALITY  caseIgnoreMatch
SYNTAX  IA5 String
MULTI-VALUED
FORMAT: A string of the form  `Type : IPName : X500Name: Encoding', where
         - Type is any one of the following types of Public key CAs:
                SecureDNS,
                CA,
                LDAP-Directory
                Inline-ISAKMP
Bhattacharya et. al.            Expires April 9 1999             [Page xvii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

         - IPName is the fully qualified domain name of the allowed
           certificate authority. It is required for Types `SecureDNS',
           `CA' and  `LDAP-Directory'
         - X500Name is the X500 DN of the CA (for Types `CA' and
           `LDAP-Directory')
         - Encoding is the acceptable certificate when source is using
           Inline ISAKMP to transfer public keys. The following values
           are allowed:
               X.509
               PKCS
               DNS-SIG`KEY
               SPKI
         Multiple values of the attribute is treated as logical OR.
DEFAULT implementation dependent


NAME  RemoteHostPublicKeyInfo
DESC  Information about remote hosts's public key. Required for public
       key based Authentication in ISAKMP
EQUALITY integerMatch
SYNTAX  INTEGER
MULTI-VALUED
FORMAT same as LocalHostPublicKeyInfo
DEFAULT implementation dependent


    The following two attributes specify minimum ISAKMP security
    association lifetimes.  A received ISAKMP negotiation request with
    values smaller than this value are rejected.


NAME  MinSecurityAssociationLifetimeKBytes
DESC  Minimum Security Association Lifetime in kiloBytes for use in
       ISAKMP negotiation
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT implementation dependent


NAME  MinSecurityAssociationLifetimeSec
DESC  Minimum Security Association Lifetime  in seconds for use in
       ISAKMP negotiation
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT implementation dependent


    Often it may be desirable to have a long lived ``ISAKMP connection"
    between two hosts, implying that the ISAKMP Security Associations
    must be automatically re-negotiated when the (negotiated) security
    association lifetime expires.  The following two attributes specify
    these values.


Bhattacharya et. al.           Expires April 9 1999             [Page xviii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

NAME  ISAKMPConnectionLifetimeKBytes
DESC  A large Lifetime in kiloBytes during which ISAKMP Security
       Associations are periodically renegotiated once they expire
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT The ISAKMP security associations are re-negotiated forever; that
         is the lifetime is infinity


NAME  ISAKMPConnectionLifetimeSec
DESC  A large Lifetime in seconds during which ISAKMP Security
       Associations are periodically renegotiated once they expire
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT The ISAKMP security associations are renegotiated forever; that
         is the lifetime is infinity


    The SecurityAssociationRefreshThreshold attribute denotes a fraction
    of negotiated ISAKMP security association Lifetime at which the
    ISAKMP security association must be refreshed.  For example, if the
    SecurityAssociationRefreshThreshold is 0.9 and the negotiated ISAKMP
    security association lifetime is 100MBytes, then a new security
    association must be negotiated when 90 MBytes has been transferred.


NAME  SecurityAssociationRefreshThreshold
DESC  Fraction of negotiated ISAKMP Security Association Lifetime at
       which an ISAKMP security association must be refreshed
EQUALITY  caseIgnoreMatch
SYNTAX  IA5String
SINGLE-VALUED
FORMAT a:b where a and b are integers
SEMANTICS a:b means a/b
DEFAULT implementation dependent


    The ISAKMPConnectionAutoStart flag denotes whether the ISAKMP
    association must be negotiated at system initialization.


NAME  ISAKMPConnectionAutoStartFlag
DESC  Flag denoting whether the ISAKMP security association must be
       automatically negotiated at system initialization
EQUALITY integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT 1 (YES), 0 (NO)
DEFAULT 0



Bhattacharya et.  al.            Expires April 9 1999             [Page xix]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

6.2.  The class IPSecSecurityAction


    This class describes the IPSec Security action and related attributes
    for a traffic flow.


NAME  IPSecSecurityAction
TYPE  Structural
DERIVED FROM PolicyAction
AUXILIARY CLASSES NONE
DESC Describes ipsec (Phase 2) security rules
MUST
       CommonName
       SecurityAction
MAY
       IPSecSecurityActionName,
       LocalIPSecTunnelEndPoint,
       RemoteIPSecTunnelEndPoint,
       LocalProxiedAddressRange,
       RemoteProxiedAddressRange,
       LocalProxiedPort,
       RemoteProxiedPort,
       ProxiedIPProtocol,
       ProxiedHostScope,
       IPSecProposalRef,
       ISAKMPActionRef,
       MinSecurityAssociationLifetimeSec,
       MinSecurityAssociationLifetimeKBytes,
       IPSecConnectionLifetimeSec,
       IPSecConnectionLifetimeKBytes,
       SecurityAssociationRefreshThreshold,
       IPSecAutoStartFlag


    The IPSECSecurityActionName is the user friendly name of this object.


NAME  IPSECSecurityActionName
DESC  The user friendly name of this entry.
EQUALITY  caseExactIA5Match
SYNTAX  IA5String
SINGLE-VALUED


    The SecurityAction attribute states the security action for the flow.


NAME  SecurityAction
DESC  Security action for the datagram
EQUALITY  caseExactStringMatch
SYNTAX IA5String
SINGLE-VALUED
FORMAT The following values are allowed
        Permit
        Deny
Bhattacharya et. al.             Expires April 9 1999              [Page xx]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

        PermitIfInboundIPSec
SEMANTICS Deny means that the packet must be dropped.


           Permit means that the packet must be allowed and further
           processing depends on the presence of the IPSecProposalRef
           attribute. If such an attribute is present, then the packet
           must be secured by IPSec; else the packet is transmitted
           in the clear.


           PermitIfInboundIPSec means that if the packet has already
           received inbound IPSec processing, then it must be processed
           according to `Permit' rules; else it must be dropped. This
           is to disallow packets that attempt to bypass inbound
           IPSec processing.


    The next two attributes specifies the two end points of the IPSec
    security association that must carry the traffic.  These attributes
    are relevant if the SecurityAction attribute is `Permit' or
    `PermitIfInboundIPSec' and there is an IPSecProposalRef attribute
    implying that the traffic must be secured by IPSec.


    For some applications, it may not be required to specify these two
    attributes and the defaults may suffice (see examples in section 8)


NAME  LocalIPSecTunnelEndPoint
DESC  Address of the local IPSec host
EQUALITY caseIgnoreMatch
SYNTAX IA5 String
SINGLE-VALUED
FORMAT The following formats are supported
        1:<IPv4address>
        2:<Host FQDN>
DEFAULT Any one of the local interface addresses for the host for
         which the policy is applicable


NAME  RemoteIPSecTunnelEndPoint
DESC  A list of potential addresses of the remote IPSec host
EQUALITY  caseIgnoreMatch
SYNTAX  IA5 String
MULTI-VALUED
FORMAT Same as LocalIPSecTunnelEndPoint
DEFAULT If the packet is a locally destined IPSec Quick Mode packet
         then the RemoteIPSecTunnelEndPoint is the source address in
         the packet (that matches the policy conditions)


         If the packet is a data packet that is to be forwarded after
         IPSec processing then the RemoteIPSecTunnelEndPoint is the
         destination address in the packet (that matches the policy
         conditions)
SEMANTICS If the SecurityAction is Permit and there is an IPSecProposalRef
Bhattacharya et. al.            Expires April 9 1999              [Page xxi]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

           attribute then, the flow described in the linked PolicyCondition
           object must be carried by an IPSec security association
           between the two hosts described by the LocalIPSecTunnelEndPoint
           and RemoteIPSecTunnelEndPoint attributes.


           The LocalIPSecTunnelEndPoint attribute represents a particular
           interface for the local host. This is useful for multihomed hosts.


           Multiple RemoteIPSecTunnelEndPoints are treated as logical OR.


    The following six attributes together define the traffic in the
    Identity payload in the IPSec Quick Mode negotiation.


    The LocalProxiedAddressRange, ProxiedIPProtocol and LocalProxiedPort
    attributes define the traffic for which the LocalIPSecTunnelEndPoint
    host acts as a proxy.


    The RemoteProxiedAddressRange, ProxiedIPProtocol and
    RemoteProxiedPort attributes define the traffic for which the
    RemoteIPSecTunnelEndPoint host acts as a proxy.


    The ProxiedHostScope attribute describes whether a separate
    IPSec Security Association is required for each pair of hosts in
    (LocalProxiedAddressRange, RemoteProxiedAddressRange) or only one is
    required for that entire range of hosts.


NAME  LocalProxiedAddressRange
DESC  Local proxied address range for use in ISAKMP Quick Mode payload
EQUALITY  caseIgnoreMatch
SYNTAX  IA5 String
SINGLE-VALUED
FORMAT identical to SourceIPAddressRange in the IPPolicyCondition class.
DEFAULT The entire address range


NAME  RemoteProxiedAddressRange
DESC  Remote proxied address range for use ISAKMP Quick Mode Identity
       payload
EQUALITY  caseIgnoreMatch
SYNTAX IA5 String
SINGLE-VALUED
FORMAT  identical to SourceIPAddressRange in the IPPolicyCondition class.
DEFAULT The entire address range


NAME ProxiedProtocol
DESC Proxied protocol for use in ISAKMP Quick Mode payload
EQUALITY caseIgnoreMatch
SYNTAX INTEGER
SINGLE-VALUED
DEFAULT The protocol value in the packet that matches the flow described
         in the linked PolicyCondition object
Bhattacharya et. al.            Expires April 9 1999             [Page xxii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998



NAME LocalProxiedPort
DESC local proxied port for use in ISAKMP Quick Mode Identity payload
EQUALITY integerMatch
SYNTAX INTEGER
SINGLE-VALUED
DEFAULT The local port number in the packet that matches the flow.


NAME RemoteProxiedPort
DESC remote proxied port for use in ISAKMP Quick Mode Identity payload
EQUALITY integerMatch
SYNTAX INTEGER
SINGLE-VALUED
DEFAULT The remote port number in the packet that matches the flow


NAME  ProxiedHostScope
DESC  Describes whether IPSec Security Association is one for each pair
       of hosts in (LocalProxiedAddressRange,RemoteProxiedAddressRange) or
       one for the entire range of hosts.
EQUALITY integerMatch
SYNTAX INTEGER
SINGLE-VALUED
FORMAT The following values are allowed
        0x00
        0x01 (i.e. Least Significant Bit(LSB) is set)
        0x02 (i.e. LSB+1 is set)
        0x03 (i.e. both LSB and LSB+1 are set)
SEMANTICS LSB corresponds to local address while LSB+1 corresponds to
           Remote address. The semantics for each bit is identical.


           If LSB is reset then the entire set of addresses defined by
           the LocalProxiedAddressRange attribute must be carried over
           one IPSec security association.


           If the LSB is set then a distinct IPSec security association
           must be used for each host in the range of the
           LocalProxiedAddressRange attribute.


           Identical logic applies for the LSB+1 bit and the
           RemoteProxiedAddressRange attribute


DEFAULT The value 0x00; meaning that only one IPSec tunnel must be
         used for the entire set of LocalProxiedAddressRange and
         RemoteAddressRange values.


    The explicit rules for matching Proxied addresses are as follows:


     1. If the packet is a locally destined IPSec Quick Mode packet (i.e.
        this host is acting as an IPSec Quick Mode responder), then the
        processing is as follows:
Bhattacharya et.  al.           Expires April 9 1999            [Page xxiii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

        The source address in the packet must be contained in the
        RemoteTunnelEndPoint values (if specified).


        If the LSB in ProxiedHostScope is set, then the IDci presented
        must be a single address within the RemoteProxiedAddresssRange
        and further, must be equal to the source address in the packet.
        Otherwise, the IDci must be entire RemoteProxiedAddressRange.


        Similarly, if the LSB+1 bit is set then the IDcr presented
        must be a single address within the LocalProxiedAddressRange
        and further, must be equal to the destination address in
        the packet.  Else, the IDcr presented must be the entire
        LocalProxiedAddressRange.


     2. If the packet is one that is to be forwarded after IPSec
        processing, then the processing is to be done as follows.


        The source address in the received packet must belong to
        LocalProxiedAddressRange and the destination address in the
        received packet must belong to the RemoteProxiedAddressRange.


        If the LSB in ProxiedHostScope is set, then source address in
        the packet must be negotiated as IDci; otherwise the entire
        LocalProxiedAddressRange must be negotiated as IDci.


        If the LSB+1 bit in ProxiedHostScope is set, then destination
        address in the packet must be negotiated as IDcr; otherwise the
        entire RemoteProxiedAddressRange must be negotiated as IDcr.


    As an example of a situation where two IPSec hosts must not
    negotiate the entire range of addresseses specified in the
    LocalProxiedAddressRange and RemoteProxiedAddressRange attributes,
    consider the remote access by users from a specific IPv4 subnet
    say 39.23.x.x.  We might wish to say, for instance, that for any
    host attempting to do IPSec Quick Mode negotiation from the subnet
    39.23.x.x, we require that the IDci presented comprise of the
    address of that host alone.  We mandate this by specifying that
    the RemoteProxiedAddressRange is 39.23.x.x, but also that the
    ProxiedHostScope attribute value is 0x02 or 0x03.  The meaning of
    these ProxiedHostScope values are described next and it implies that
    the source address in the received Quick Mode packet must be used
    to derive the IDci presented.  This approach avoids having multiple
    IPSec actions, each containing single LocalProxiedAddressRange or
    RemoteProxiedAddressRange values and provides flexibility in defining
    the traffic to be protected by an IPSec security association.


    The IPSecProposalRef attribute contains a list of IPSec Proposals for
    the flow.  Since LDAP does not support ordered lists, a composite
    string is required to define ordered IPSec proposals.


Bhattacharya et. al.            Expires April 9 1999             [Page xxiv]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

NAME  IPSecProposalRef
DESC  Ordered list of absolute DNs of of IPSecProposal objects
EQUALITY caseIgnoreMatch
SYNTAX    IA5String
MULTI-VALUED
FORMAT The format is `pref:IPSecProposalDN' where
         - pref is an integer denoting the relative preference of this
           proposal
         - IPSecProposalDN denotes the distinguishing name of an
           IPSecProposal object representing this proposal


    Sometimes there can be multiple ISAKMPAction objects for the flow,
    e.g.  if there are multiple ISAKMP security associations between
    the two IPSec hosts protecting this flow.  In such scenarios, an
    ISAKMPActionRef attribute describes the particular ISAKMP security
    association that must carry this traffic.


NAME  ISAKMPActionRef
DESC  Absolute distinguised name of the ISAKMPAction object that
       describes the  ISAKMP action used to  carry the IPSec traffic
EQUALITY distinguishedNameMatch
SYNTAX  DN
SINGLE-VALUED


    The rest of the attributes are as defined in Section 6.1 but apply to
    ISAKMP Quick Mode traffic.

7.  Other classes

7.1.  The class ISAKMPProposal


    This class describes the attributes of an ISAKMP (phase one)
    proposal.


NAME  ISAKMPProposal
DESC  Describes ISAKMP proposal attributes
DERIVED FROM Top
AUXILIARY CLASSES NONE
MUST
      CommonName,
      ISAKMPAuthenticationMethod,
      ISAKMPHashAlgorithm,
      ISAKMPCipherAlgorithm,
MAY
      ISAKAMPProposalName,
      ISAKMPPrfAlgorithm,
      ISAKMPCipherKeyLength,
      ISAKMPCipherKeyRounds,
      DefaultDiffieHellmanGroupId,
Bhattacharya et. al.            Expires April 9 1999              [Page xxv]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

      PrivateDiffieHellmanGroupRef,
      SecurityAssociationLifetimeSec,
      SecurityAssociationLifetimeKBytes


    The ISAKMPProposalName defines the user friendly name of this entry.


NAME  ISAKMPProposalName
DESC  The user friendly name of this entry. The Name related  attributes are
       only for ease of user administration
EQUALITY  caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED


    The ISAKMPAuthenticationMethod attribute defines the ISAKMP/Oakley
    authentication method.


NAME  ISAKMPAuthenticationMethod
DESC  Authentication method for key exchange in ISAKMP
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The acceptable values for are given in [4]
DEFAULT Implementation dependent


NAME  ISAKMPHashAlgorithm
DESC  Hash Algorithms for use in ISAKMP
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The acceptable values for are given in [4]
DEFAULT Implementation dependent


NAME  ISAKMPCipherAlgorithm
DESC  Cipher Algorithms for use in ISAKMP
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The acceptable values for are given in [4]
DEFAULT Implementation dependent


NAME  ISAKMPPRFAlgorithm
DESC  PseudoRandom function algorithm for use in ISAKMP
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The acceptable values for are given in [4]
DEFAULT The value corresponding to HMAC


    The following two attributes are related to some special ISAKMP
    ciphers.
Bhattacharya et. al.            Expires April 9 1999             [Page xxvi]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

NAME  ISAKMPCipherKeyLength
DESC  Keylength for use when ISAKMP Cipher algorithms are CAST, RC5 or
       Blowfish
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT Not applicable


NAME  ISAKMPCipherKeyRounds
DESC  Key rounds for use with some ISAKMP Cipher algorithms
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT Not applicable


    ISAKMPCipherKeyRounds is not used at present, but may be needed for
    some new cipher algorithm.


    DefaultDiffieHellmanGroupId attribute specifies the well known Diffie
    Hellman group Ids in case these are to be used.  If on the other hand
    private groups are to be used, then the PrivateDiffieHellmanGroupRef
    provides a reference to the PrivateDiffieHellmanGroup object
    describing the group attributes.


NAME  DefaultDiffieHellmanGroupId
DESC  Default Diffie Hellman group ids: 1,2,3,4 defined in [4]
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT Implementation dependent


NAME  PrivateDiffieHellmanGroupRef
DESC  Absolute DN of an DiffieHellmanGroup object
EQUALITY  distinguishedNameMatch
SYNTAX  DN
SINGLE-VALUED
DEFAULT Not applicable


    The following two attributes specify security association lifetimes.


NAME  SecurityAssociationLifetimeKBytes
DESC  Security Association Lifetime time in KBytes
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT Implementation dependent


NAME  SecurityAssociationLifetimeSec
DESC  Security Association Lifetime time in seconds
EQUALITY  integerMatch
Bhattacharya et. al.           Expires April 9 1999             [Page xxvii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT Implementation dependent

7.2.  The class IPSecProposal

    This class describes an IPSec proposal for ISAKMP/Oakley Quick Mode
    negotiation.  A proposal consists of combinations of AH, ESP and
    IPCOMP protocols.


    The transform attributes of the AH protocol are specified by the
    AHProtocolTransformRef attribute that refers to an appropriate
    IPSecTransform object (described in section 7.3).


    Similarly, the ESPProtocolTransformRef attribute specifies
    the transforms associated with the ESP protocol and the
    IPCOMPProtocolTransformRef attribute specifies the transforms
    associated with the IPCOMP protocol.  The ESPProtocolTransformRef
    and IPCOMPProtocolTransformRef attribute refers to an appropriate
    IPSecTransform objects (described in section 7.3).


    The attributes AHProtocolTransformRef, ESPProtocolTransformRef
    and IPCOMPProtocolTransformRef are all taken as logical ANDs when
    presented together.  For example, when both an AHProtocolTransformRef
    and an ESPProtocolTransformRef are present, then both AH and ESP must
    be negotiated together.


    The class definition is


NAME  IPSecProposal
DESC  Describes an IPSEC Proposal
DERIVED FROM  Top
MUST
      CommonName,
      PerfectForwardSecrecy
MAY
      IPSecProposalName,
      DefaultDiffieHellmanGroupId,
      PrivateDiffieHellmanGroupRef,
      AHProtocolTransformRef,
      ESPProtocolTransformRef,
      IPCOMPProtocolTransformRef


    The attribute definitions are given below.


NAME  ISAKMPProposalName
DESC  The user friendly name of this entry.
EQUALITY  caseExactIA5Match
SYNTAX    IA5String
Bhattacharya et. al.           Expires April 9 1999            [Page xxviii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

SINGLE-VALUED


    The PerfectForwardSecrecy attribute denotes whether a fresh Diffie
    Hellman Exchange is required in IPSec Quick Mode.  If this attribute
    value is 1 (i.e.  fresh Diffie Hellman exchange is required) then
    one of the Diffie Hellman attributes DefaultDiffieHellmanGroupId,
    PrivateDiffieHellmanGroupRef must be present in each of the referred
    IPSecTransform objects.


NAME  PerfectForwardSecrecy
DESC  Perfect forward secrecy requirement in IPSec Quick Mode
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The following values are defined
        1 (Required)
        0 (not required)


NAME  DefaultDiffieHellmanGroupId
DESC  Default Diffie Hellman group ids: 1,2,3,4 defined in [4]
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED


NAME  PrivateDiffieHellmanGroupRef
DESC  Absolute DN of a private DiffieHellmanGroup object
EQUALITY  distinguishedNameMatch
SYNTAX  DN
SINGLE-VALUED


    Note that the following reference object lists are defined as strings
    in order to emulate ordered lists which is currently not supported in
    LDAP.


NAME  AHProtocolTransformRef
DESC  Ordered list of absolute distinguished names of IPSecTransform objects
       corresponding to AH protocol
EQUALITY  caseIgnoreMatch
SYNTAX  IA5 String
MULTI-VALUED
FORMAT The format is `pref:IPSecTransformDN' where
         - pref is an integer denoting the relative preference of
           the transform. Lower number is higher preference.
         - IPSecTransformDN denotes the distinguishing name of an
           IPSecTransform object corresponding to the AH protocol


NAME  ESPProtocolTransformRef
DESC  Ordered list of absolute distinguished names of IPSecTransform objects
       corresponding to ESP protocol
EQUALITY caseIgnoreMatch
Bhattacharya et. al.            Expires April 9 1999             [Page xxix]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

SYNTAX  IA5 String
MULTI-VALUED
FORMAT The format is `pref:IPSecTransformDN' where
       - pref is an integer denoting the relative preference of
         the transform. Lower number is higher preference.
       - IPSecTransformDN denotes the distinguishing name of an
         IPSecTransform object corresponding to the ESP protocol


NAME  IPCOMPProtocolTransformRef
DESC  Ordered list of absolute distinguished names of IPSecTransform objects
       corresponding to IPCOMP protocol
EQUALITY distinguishedNameMatch
SYNTAX  DN
MULTI-VALUED
FORMAT The format is `pref:IPSecTransformDN' where
       - pref is an integer denoting the relative preference of the
         transform. Lower number is higher preference.
       - IPSecTransformDN denotes the distinguishing name of an
         IPSecTransform object corresponding to the IPCOMP protocol

7.3.  The class IPSecTransform

    This class describes the attributes of an IPSec Quick Mode transform.


NAME  IPSecTransform
DESC  Describes IPSec transform attributes
DERIVED FROM  Top
MUST
      CommonName
      IPSecProtocolId
MAY
      IPSecTransformName,
      AHIntegrityAlgorithm,
      ESPIntegrityAlgorithm,
      ESPCipherAlgorithm,
      ESPCipherKeyLength,
      ESPCipherKeyRounds,
      IPCOMPCompressAlgorithm,
      IPCOMPVendorCompressAlgorithm,
      EncapsulationMode,
      SecurityAssociationLifetimeSec,
      SecurityAssociationLifetimeKBytes


NAME  ISAKMPTransformName
DESC  The user friendly name of this entry.The Name related  attributes are
       only for ease of user administration.
EQUALITY  caseExactIA5Match
SYNTAX    IA5String
SINGLE-VALUED
Bhattacharya et.  al.            Expires April 9 1999             [Page xxx]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

    The IPSecProtocolId attribute denotes the IPSec protocol (e.g.
    AH, ESP, IPCOMP) corresponding to this transform object.  For
    example, if the transform object denotes an AH`MD5 transform then the
    IPSecProtocolId is IPSEC`AH.


NAME  IPSecProtocolId
DESC  IPSec protocol corresponding to this transform
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The acceptable values are given in [4].


    The AHIntegrityAlgorithm and ESPIntegrityAlgorithm attributes
    denote the integrity transform (e.g.  MD5, SHA etc.)  in AH and ESP
    protocols respectively.


NAME  AHIntegrityAlgorithm
DESC  Integrity Algorithm for use in AH
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The acceptable values are given in [4].
DEFAULT Not applicable


NAME  ESPIntegrityAlgorithm
DESC  Integrity Algorithm for use in ESP
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The acceptable values are given in [4].
DEFAULT Not applicable


    The EncapsulationMode describes the Tunnel or transport encapsulation
    mode.


NAME  EncapsulationMode
DESC  Encapsulation Mode: Tunnel or Transport
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The acceptable values for in [4].
DEFAULT: the integer value corresponding to the Transport Mode


    The ESPCipherAlgorithm attribute denotes the integrity transform
    (e.g.  3DES, IDEA etc.)  in ESP.


NAME  ESPCipherAlgorithm
DESC  Cipher Algorithms for use in ESP
EQUALITY  integerMatch
SYNTAX  INTEGER
Bhattacharya et. al.            Expires April 9 1999             [Page xxxi]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

SINGLE-VALUED
FORMAT The acceptable values are given in [4]
DEFAULT Not applicable


NAME  ESPCipherKeyLength
DESC  Keylength for use when ESP Cipher algorithms are CAST, RC5 or
       Blowfish
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT Not applicable


NAME  ESPCipherKeyRounds
DESC  Key rounds for use with some ESP Cipher algorithms
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT Not applicable


    ESPCipherKeyRounds is not used at present, but may be needed for some
    new cipher algorithm.


NAME  IPCOMPCompressAlgorithm
DESC  Compression Algorithms for use in IPCOMP
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
FORMAT The acceptable values are given in [4]
DEFAULT Implementation dependent


NAME  IPCOMPVendorCompressAlgorithm
DESC  Vendor specific Compression Algorithms for use in IPCOMP
EQUALITY integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT Not applicable


    The VendorCompressAlgorithm attribute must be present when
    CompressAlgorithm represents OUI.


    The following two attributes specify security association lifetimes.
    If a proposal consists of multiple protocols such as AH and ESP, then
    the lifetime values applies to each protocol as they are negotiated
    together.


NAME  SecurityAssociationLifetimeKBytes
DESC  Security Association Lifetime in KBytes
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
Bhattacharya et. al.           Expires April 9 1999             [Page xxxii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

DEFAULT Implementation dependent


NAME  SecurityAssociationLifetimeSec
DESC  Security Association Lifetime in seconds
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
DEFAULT Implementation dependent

7.4.  The class PrivateDiffieHellmanGroup

    This class defines a private Diffie Hellman Group.


NAME  PrivateDiffieHellmanGroup
DESC  Describes a private Diffie Hellman group attributes
DERIVED FROM Top
MUST
      CommonName
      DHGroupType
MAY
      PrivateDHGroupName,
      DHPrime,
      DHGenerator,
      DHGenerator1,
      DHGenerator2,
      DHCurveA,
      DHCurveB,
      DHFieldSize,
      DHOrder


    The attribute definitions are as follows.


NAME  DHGroupType
DESC  The diffie Hellman group type for a DHGroup object:
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED
SEMANTICS The acceptable values are given in [4]


NAME  DHFieldSize
DESC  GF size for elliptic curve groups
EQUALITY  integerMatch
SYNTAX  INTEGER
SINGLE-VALUED


NAME  DHGenerator
DESC  Group Generator
EQUALITY  caseIgnoreMatch
SYNTAX  IA5 String
Bhattacharya et. al.           Expires April 9 1999            [Page xxxiii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

SINGLE-VALUED


NAME  DHCurveA
DESC  Group Curve A for elliptic curve groups
EQUALITY  caseIgnoreMatch
SYNTAX  IA5 String
SINGLE-VALUED


NAME  DHCurveB
DESC  Group Curve B for elliptic curve groups
EQUALITY  caseIgnoreMatch
SYNTAX  IA5 String
SINGLE-VALUED


NAME  DHOrder
DESC  Group Order for elliptic curve groups
EQUALITY  caseIgnoreMatch
SYNTAX  IA5 String
SINGLE-VALUED

8.  VPN Schema Usage Examples


    In this section we describe some usage scenarios for VPNs.  The
    intent is not to be very complete in specifying all the attributes,
    rather to show how the important attributes are to be defined.  The
    objects are all written in LDIF notation.

8.1.  Scenario I: Intranet communication

       - - - - - - - - - - - - - - - - - - - - - - - - - -
      |                                                   |
      |                                                   |
      S1, TCP, any port  ---------------------> S2, TCP, port 8000-8080
      |                                                   |
      |                      Intranet                     |
      - - - - - - - - - - - - - - - - - - - - - - - - - -

    The requirements are:


     -  All hosts on subnet S1 must use IPSec to communicate to hosts on
        subnet S2 and (HTTP) ports 8000-8080


     -  Only hosts on subnet S1 are allowed to initiate connections


     -  No intermediate gateways are required



Bhattacharya et.  al.           Expires April 9 1999            [Page xxxiv]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

8.1.1.  ISAKMP rules for each host in S1 and S2


    Each host in S1 and S2 needs to have the following rule.


     dn: cn=S1-S2-isakmp-rule, o=XYZ, c=US
     Objectclass: Policy
     PolicyScope: ISAKMP
     PolicyType:  ISAKMP
     PolicyConditionRef: cn=S1-S2-isakmp-traffic,o=XYZ, c=US,
     PolicyActionRef: cn=S1-S2-isakmp-action, o=XYZ, c=US


     dn: cn=S1-S2-isakmp-traffic, o=XYZ, c=US
     Objectclass: IPPolicyCondition
     SourceAddressRange: S1
     DestinationAddressRange: S2
     IPProtocolRange: 17 (i.e. UDP)
     SourcePortRange: 500 (i.e. ISAKMP port)
     DestinationPortRange: 500 (i.e. ISAKMP port)


     dn: cn=S1-S2-isakmp-action, o=XYZ, c=US
     Objectclass: ISAKMPAction
     ISAKMPProposalRef: cn=S1-S2-isakmp-proposal,o=XYZ, c=US


     dn: cn=S1-S2-isakmp-proposal, o=XYZ, c=US
     Objectclass: ISAKAMPProposal
     ISAKMPHashAlgorithm: 2(i.e. SHA)
     ISAKMPAuthenticationMethod: 4 (i.e. RSA encryption)
     ISAKMPCipherAlgorithm: 5(i.e. 3DES)
     SecurityAssociationLifetimeSec: 3600


    Note that there must be no IPPolicyCondition object with S2 as the
    source address range and S1 as the destination address range, since
    hosts in S2 are not allowed to initiate ISAKMP negotiations.

8.1.2.  IPSec Rules for each host in S1

    For the sake of illustration suppose that the following two IPSec
    proposals need to be negotiated.


     -  the first (preferred) proposal consists of only ESP protocol with
        3DES as cipher and SHA as the integrity algorithm,


     -  the second proposal consists of both AH and ESP protocols; SHA is
        the integrity algorithm for AH while 3DES is the cipher for ESP.
        There is no integrity algorithm for ESP in this proposal.


    Three IPSec rules are needed for hosts on subnet S1::



Bhattacharya et.  al.            Expires April 9 1999            [Page xxxv]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

     1. one rule for handling data packets from S2 to S1:  this states
        that such packets must arrive at S1 within an IPSec security
        association.  Because of this rule, it would not be possible to
        send non-IPSec packets from S2 to S1 on src port 8000-8080.


               dn: cn=S2-S1-HTTP-rule, o=XYZ, c=US
               Objectclass: Policy
               PolicyScope: IPSec
               PolicyType: IPSecDataRemote
               PolicyConditionRef: cn=S2-S1-HTTP-traffic, o=XYZ, c=US
               PolicyActionRef: cn=inboundIPSecAction, o=XYZ,c=US


               dn: cn=S2-S1-HTTP-traffic, o=XYZ, c=US
               Objectclass: IPPolicyCondition
               SourceIPAddressRange: S2
               DestinationIPAddressRange: S1
               SourcePortRange: 8000:8080
               IPProtocolRange: 4 (i.e. TCP)


               dn: cn= inboundIPSecIPSecAction, o=XYZ, c=US
               Objectclass: IPSecSecurityAction
               SecurityAction: PermitIfInboundIPSec


     2. one rule for data packets from S1 to S2:  this states that such
        packets must be secured by IPSec processing.


                dn: cn= S1-S2-HTTP-rule, o=XYZ, c=US
                Objectclass: Policy
                PolicyScope: IPSec
                PolicyType: IPSecDataLocal
                PolicyConditionRef: cn=S1-S2-HTTP-traffic, o=XYZ, c=US
                PolicyActionRef: cn=S1-S2-HTTP-IPSec-action, o=XYZ,c=US


                dn: cn=S1-S2-HTTP-traffic, o=XYZ, c=US
                Objectclass: IPPolicyCondition
                SourceIPAddressRange: S1
                DestinationIPAddressRange: S2
                DestinationPortRange: 8000:8080
                IPProtocolRange: 4 (i.e. TCP)


                dn: cn= S1-S2-HTTP-IPSec-action, o=XYZ, c=US,
                Objectclass: IPSecSecurityAction
                SecurityAction: Permit
                LocalProxiedAddressRange: S1
                RemoteProxiedAddressRange: S2
                LocalProxiedPort: 0
                RemoteProxiedPort: 8000 : 8080
                ProxiedProtocol: 4
                ProxiedHostScope: 0x11
                IPSecProposalRef: 1: cn= ESPProposal, o=XYZ, c=US,
Bhattacharya et. al.           Expires April 9 1999             [Page xxxvi]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

                IPSecProposalRef: 2: cn= AHESPProposal, o=XYZ, c=US


                dn: cn=ESPProposal,o=XYZ, c=US
                Objectclass: IPSecProposal
                ESPProtocolTransformRef: 1: cn= AuthEncryptTransform,o=XYZ, c=US


                dn: cn=AHESPProposal, o=XYZ, c=US
                Objectclass: IPSecProposal
                AHProtocolTransformRef: 1: cn= AuthTransform, o=XYZ, c=US
                ESPProtocolTransformRef: 1: cn= EncryptTransform, o=XYZ, c=US


                dn: cn= AuthEncryptTransform,o=XYZ, c=US,
                Objectclass: IPSecTransform
                IPSecProtocolId: 3 (i.e. IPSEC`PROTO`ESP)
                ESPCipherAlgorithm: 3 (i.e. 3DES)
                ESPIntegrityAlgorithm: 2 (i.e. HMAC-SHA-1)
                EncapsulationMode: 2 (i.e. transport)
                SecurityAssociationLifetimeSec: 3600


                dn: cn= AuthTransform,o=XYZ, c=US
                Objectclass: IPSecTransform
                IPSecProtocolId: 2 (i.e. IPSEC`PROTO`AH)
                AHIntegrityAlgorithm: 2 (i.e. HMAC-SHA-1)
                EncapsulationMode: 1 (i.e. tunnel)
                SecurityAssociationLifetimeSec: 3600


                dn:  cn= EncryptTransform, o=XYZ, c=US
                Objectclass: IPSecTransform
                IPSecProtocolId: 3 (i.e. IPSEC`PROTO`ESP)
                ESPCipherAlgorithm: 3 (i.e. 3DES)
                EncapsulationMode: 2 (i.e. transport)
                SecurityAssociationLifetimeSec: 3600


     3. one for IPSec packets from S1 to S2 (that is, packets with
        protocol field AH or ESP). This would state whether S1 and S2 can
        communicate directly or a gateway has to be traversed.


                dn: cn= S1-S2-AHESP-rule, o=XYZ, c=US
                Objectclass: Policy
                PolicyType: IPSecDataLocal
                PolicyConditionRef: cn=S1-S2-AHESP-traffic, o=XYZ, c=US
                PolicyActionRef: cn=clearIPSecSecurityAction, o=XYZ, c=US


                dn: cn=S1-S2-AHESP-traffic, o=XYZ, c=US,
                Objectclass: IPPolicyCondition
                SourceIPAddressRange: S1
                DestinationIPAddressRange: S2
                IPProtocolRange: 50-51 (i.e. AH and ESP)


                dn: cn=clearIPSecSecurityAction, o=XYZ, c=US
Bhattacharya et. al.           Expires April 9 1999            [Page xxxvii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

                Objectclass: IPSecSecurityAction
                SecurityAction: Permit

8.1.3.  IPSec Rules for each host in S2

    The situation for hosts in S2 is symmetric to those for S1, except
    that a policy is needed for hosts in S2 to respond to ISAKMP Quick
    Mode negotiations.  Hosts in S1 do not need such a policy since they
    only initiate ISAKMP.


    Such a policy is needed since the packet header in ISAKMP Quick
    Mode is different than in a data packet and we want to make it
    straightforward for hosts to match policies.


    Hence for hosts in S2, the following IPSec rules are needed:


     -  Three rules as described in section 8.1.2 with the difference
        that source and destination addresses, port numbers etc.  must be
        reversed.


     -  An extra rule that enables hosts on S2 to respond to ISAKMP Phase
        2 signalling.


                dn: cn=S1-S2-isakmp-QuickMode-rule, o=XYZ, c=US
                Objectclass: Policy
                PolicyScope: IPSec
                PolicyType: IPSecPhase2
                PolicyConditionRef: cn=S1-S2-isakmp-traffic,o=XYZ, c=US,
                PolicyActionRef: cn=S2-HTTP-S1-ipsec-action, o=XYZ, c=US


                dn: cn= S2-HTTP-S1-IPSec-action, o=XYZ, c=US,
                Objectclass: IPSecSecurityAction
                SecurityAction: Permit
                LocalProxiedAddressRange: S2
                RemoteProxiedAddressRange: S1
                LocalProxiedPort: 8000 : 8080
                RemoteProxiedPort: 0
                ProxiedProtocol: 4
                ProxiedHostScope: 0x11
                IPSecProposalRef: 1: cn= ESPProposal, o=XYZ, c=US,
                IPSecProposalRef: 2: cn= AHESPProposal, o=XYZ, c=US


        The IPSecProposal objects are defined in section 8.1.2.

8.2.  Scenario II: Remote access to intranet via an ISP

    This case differs from the previous in that subnet S2 is behind a
    security gateway GW2.  The traffic between subnets S1 and S2 on
Bhattacharya et.  al.          Expires April 9 1999          [Page xxxviii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

    destination port range 8000-8080 must be sent within an per host
    IPSec tunnel between an host on S1 and GW2.


                               ----------------------------------
                             |                                  |
     S1,TCP ---Internet---  GW2---Intranet-------->S2,TCP,HTTP ports

         <-----------------end-to-end IPSec------------>
         <---outer IPSec --->|                                  |
              tunnel          ----------------------------------

8.2.1.  Rules for each host in S1

    Identical to those in section 8.1 since from S2's point of view,
    nothing has changed.

8.2.2.  Rules for each host in S2

    ISAKMP Rules:

    An additional rule is required for communication between hosts
    on S1 and GW2.  Typically the traffic profile described in the
    PolicyCondition object for S1-S2 rule will be broad enough to include
    the S1 and GW2.  If this is not the case then a new rule has to be
    added as in section 8.1.1 by replacing the subnet S2 with the gateway
    GW2.


    IPSec rules:


    The difference between this case and the intranet case in section
    8.1.2 is that hosts on S1 now have to send S1-S2 traffic via the
    gateway GW2.


    To accomplish this, simply replace the rule whose DN equals ``cn=
    S1-S2-AHESP-rule, o=XYZ, c=US'' in section 8.1.2 by the following two
    rules:  (Note that objects not defined here are defined earlier in
    this section)


     1. One rule which states that IPSec packets between S1 and S2 must
        be sent within an IPSec tunnel between S1 and GW2.


                dn: cn= S1-S2-AHESP-rule, o=XYZ, c=US
                Objectclass: Policy
                PolicyScope: IPSec
                PolicyType: IPSecDataLocal
                PolicyConditionRef: cn=S1-S2-AHESP-traffic, o=XYZ, c=US
                PolicyActionRef: cn=AHTunnelSecurityAction, o=XYZ, c=US


Bhattacharya et. al.           Expires April 9 1999             [Page xxxix]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

                dn: cn=AHTunnelSecurityAction, o=XYZ, c=US
                Objectclass: IPSecSecurityAction
                SecurityAction: Permit
                RemoteIPSecTunnelEndPoint: GW2
                LocalProxiedAddressRange: S1
                RemoteProxiedAddressRange: S2
                ProxiedProtocol: 0
                LocalProxiedPort:0
                RemoteProxiedPort:0
                ProxiedHostScope: 0x11
                IPSecProposalRef: cn=AuthTunnelProposal, o=XYZ, c=US


                dn:  cn= AuthTunnelProposal,o=XYZ, c=US
                Objectclass: IPSecProposal
                IPSecTransformRef: 1: cn= AuthTransform, o=XYZ, c=US


     2. one rule that states that hosts on S1 and GW2 need not traverse
        any intermediate gateways.


                dn: cn=S1-GW2-AHESP-rule, o=XYZ, c=US
                Objectclass: Policy
                PolicyScope: IPSec
                PolicyType: IPSecDataLocal
                TrafficProfileRef: cn=S1-GW2-AHESP-traffic, o=XYZ, c=US
                PolicyActionRefe: cn=clearIPSecSecurityAction, o=XYZ,c=US


                dn: cn=S1-GW2-AHESP-traffic, o=XYZ, c=US
                Objectclass: PolicyCondition
                SourceAddressRange: S1
                DestinationAddressRange: GW2
                IPProtocolRange: 50:51
8.2.3.  Rules for GW2


    Only the IPSec rules are described here.  The ISAKMP rule between
    GW2 and hosts on S1 can be generated easily.  Note that objects not
    defined here are defined earlier in this section.


     1. A rule that states that packets from S1 to S2 on destination
        port 8000-8080 must be received inside of an IPSec security
        association, and then must be sent out in the clear.


                 dn: cn= S1-S2-GatewayRemoteAccessRule, o=XYZ, c=US
                 Objectclass: Policy
                 PolicyScope: IPSec
                 PolicyType: IPSecDataRemote
                 TrafficProfileRef: cn=S1-S2-HTTP-traffic, o=XYZ, c=US
                 PolicyActionRef: cn=S1-GW2-inbound-SecurityAction, o=XYZ,c=US


Bhattacharya et. al.             Expires April 9 1999              [Page xl]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

                 dn: cn=S1-GW2-inbound-SecurityAction, o=XYZ, c=US
                 Objectclass: IPSecSecurityAction
                 SecurityAction:  PermitIfInboundIPSec


     2. A rule that states that packets from S2 to S1 on source port 8000
        to 8080 must be secured by ipsec on the outbound path.


                 dn: cn= S2-S1-GatewayRemoteAccessRule, o=XYZ, c=US
                 Objectclass: Policy
                 PolicyScope: IPSec
                 PolicyType: IPSecDataLocal
                 TrafficProfileRef: cn=S2-HTTP-S1-traffic, o=XYZ, c=US
                 PolicyActionRef: cn=GW2-S1-HTTP-SecurityAction, o=XYZ, c=US


                 dn: cn=GW2-S1-HTTP-SecurityAction, o=XYZ, c=US
                 Objectclass: IPSecSecurityAction
                 SecurityAction: Permit
                 LocalIPSecTunnelEndpoint: GW2
                 LocalProxiedAddressRange: S2
                 RemoteProxiedAddressRange: S1
                 ProxiedProtocol: 0
                 LocalProxiedPort:0
                 RemoteProxiedPort:0
                 ProxiedHostScope: 0x11
                 ProxiedProtocol: 4(i.e. TCP)
                 IPSecProposalRef: cn=AHTunnelProposal, o=XYZ, c=US


     3. A rule that states that GW2 and hosts on S1 can communicate
        directly.


                 dn: cn=GW2-S1-AHESP-rule, o=XYZ, c=US
                 Objectclass: Policy
                 PolicyScope: IPSec
                 PolicyType: ISAKMPDataLocal
                 TrafficProfileRef: cn=GW2-S1-EHESP-traffic, o=XYZ, c=US
                 PolicyActionRef: cn=clearIPSecSecurityAction, o=XYZ, c=US


                 dn: cn=GW2-S1-AHESP-traffic, o=XYZ, c=US
                 Objectclass: PolicyCondition
                 SourceAddressRange: GW2
                 DestinationAddressRange: S1
                 IPProtocolRange: 50-51 (i.e. AH and ESP)


     4. A rule for GW2 to respond to ISAKMP Quick Mode packets from hosts
        in S1.


                 dn: cn=S1-GW2-isakmp-QuickMode-rule, o=XYZ, c=US
                 Objectclass: Policy
                 PolicyScope: IPSec
                 PolicyType:  ISAKMPPhase2
Bhattacharya et. al.            Expires April 9 1999              [Page xli]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

                 PolicyConditionRef: cn=S1-GW2-isakmp-traffic,o=XYZ, c=US,
                 PolicyActionRef: cn=GW2-S1-HTTP-SecurityAction, o=XYZ, c=US


                 dn: cn=S1-GW2-isakmp-traffic, o=XYZ, c=US
                 Objectclass: IPPolicyCondition
                 SourceAddressRange: S1
                 DestinationAddressRange: GW2
                 IPProtocolRange: 17 (i.e. UDP)
                 SourcePortRange: 500 (i.e. ISAKMP port)
                 DestinationPortRange: 500 (i.e. ISAKMP port)

8.3.  Scenario III: Corporate Branch office to Main office

    Suppose that hosts on subnets S1 and S2 are not IPSec enabled.
    therefore traffic initiated by any host on subnet S1 and destined
    to any host subnet S2 and port 80 is to be carried by the security
    gateways GW1 and GW2 within an IPSec security association in tunnel
    mode as show below.

           ----------------                   ---------------------
         |               |                   |                   |
                Intranet                        Intranet
       S1,TCP,-----------GW1-----Internet---GW2---------->S2,TCP,
        Any port         <-----IPSec ------>           port 8000-8080
                               AH tunnel
         |               |                   |                   |
          ---------------                     -------------------

    Rules for GW1 are described here since those for GW2 are completely
    symmetric except the ISAKMP Quick Mode responder rule.  Also, only
    IPSec rules are described since ISAKMP rules are straightforward.
    Note that objects not defined here are defined earlier in this
    section.


     1. The first rule for the gateway GW1 concerns packets received from
        hosts on subnet S1 destined to hosts on subnet S2 and on port
        8000-8080.  These packets must be sent to GW2 within ONE IPSec
        tunnel.  Note the use of the ProxiedHostScope attribute.


                dn: cn= S1-S2-BrOffRule, o=XYZ, c=US
                Objectclass: Policy
                PolicyScope: IPSec
                PolicyType: IPSecDataLocal
                TrafficProfileRef: cn=S1-S2-HTTP-traffic, o=XYZ, c=US
                PolicyActionRef: cn=S1-S2-BrOffSecAction, o=XYZ,c=US


                dn: cn=S1-S2-BrOffSecAction, o=XYZ, c=US
                Objectclass: IPSecSecurityAction
                SecurityAction: Permit
Bhattacharya et. al.            Expires April 9 1999             [Page xlii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

                LocalIPSecTunnelEndPoint: GW1
                RemoteIPSecTunnelEndPoint: GW2
                LocalProxiedAddressRange: S1
                RemoteProxiedAddressRange: S2
                LocalProxiedPort: 0
                RemoteProxiedPort: 8000 : 8080
                ProxiedProtocol: 4
                ProxiedHostScope: 0x00
                IPSecProposalRef: cn=AHTunnelProposal, o=XYZ, c=US


     2. The second rule states that GW1 and GW2 can communicate directly
        without any intermediate gateways.


                dn: cn=GW1-GW2-AHESP-rule, o=XYZ, c=US
                Objectclass: Policy
                PolicyScope: IPSec
                PolicyType: IPSecDataLocal
                TrafficProfileRef: cn=GW1-GW2-AHESP-traffic, o=XYZ, c=US
                PolicyActionRef: cn=clearIPSecSecurityAction, o=XYZ, c=US


                dn: cn=GW1-GW2-AHESP-traffic, o=XYZ, c=US
                Objectclass: PolicyCondition
                SourceIPAddressRange: GW1
                DestinationIPAddressRange: GW2
                IPProtocolRange: 50-51 (i.e. AH and ESP)


     3. The third rule states that packets from S2 to S1 must receive
        inbound IPSec processing and then forwarded in the clear.


                dn: cn= S2-S1-BrOffRule, o=XYZ, c=US
                Objectclass: Policy
                PolicyScope: IPSec
                PolicyType: PolicyDataRemote
                PolicyConditionRef: cn=S2-S1-HTTP-traffic, o=XYZ, c=US
                PolicyActionRef: cn=inboundIPSecAction, o=XYZ,c=US
9.  Security Considerations


    This draft presents a policy model of the IPSec documents.  All
    security considerations within those actual specification MUST be
    considered prior to implementing a policy architecture.
References


    [1] R. Atkinson, ``Security Architecture for the Internet Protocol'',
        draft-ietf-ipsec-arch-sec-01



Bhattacharya et. al.           Expires April 9 1999             [Page xliii]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

    [2] D. Maughan, M. Schertler, M. Schneider, J. Turner, ``
        Internet Security Association and Key Management'',
        draft-ietf-ipsec-isakmp-09


    [3] M. Wahl, T. Howes, S. Kille, ``Lightweight Directory Access
        Protocol (v3)'', RFC 2251


    [4] D. Harkins, ``The Internet Key Exchange'', draft-ietf-ipsec-isakmp-oakl*
 *ey-06


    [5] D. Piper, ``The Internet IP Security Domain Of Interpretation for
        ISAKMP'', draft-ietf-ipsec-doi-07


    [6] R. Rajan, J-C. Martin, S. Kamat, M. See and R. Chaudhury,
        ``Schema for Differentiated Services and Integrated Services in
        Networks'', draft-ietf-policy-qosschema-00.txt


    [7] S. Judd and J. Strassner, ``Directory Enabled Networks -
        Information Model and Base Schema'' - Draft v3.0r5 DEN
        Specifications, September 1998


    [8] Common Information Model (CIM) Specification, Desktop Management
        Task Force, Version 2.0, Mar. 1998.


    [9] R. Pereira and P. Bhattacharya, ``IPSec Policy Data Model'',
        draft-ietf-ipsec-policy-model-00.txt

Acknowledgments

    The IBM authors would like to thank Pau Cheng, Will Fiveash,
    Skip Booth and Charlie Kunzinger for many useful discussions and
    suggestions.

Contact Address

Partha P Bhattacharya
Phone: (914) 784-7981
Email: partha@watson.ibm.com
IBM T. J. Watson Research Center
Rob Adams
Phone: (425) 558-2285
Email: radams@cisco.com
Cisco Systems
Roy Pereira
Phone: (613) 599-3610 x 4808
Bhattacharya et.  al.            Expires April 9 1999            [Page xliv]


Internet Draft  draft-ietf-ipsec-policy-schema-00.txt       October 9 1998

Email: rpereira@timestep.com
TimeStep Corporation


William Dixon
Phone: (425) 703-8729
Email: wdixon@microsoft.com
Microsoft Corporation


Raju Rajan
Phone: (914) 784-7260
Email: raju@watson.ibm.com
IBM T. J. Watson Research Center


Bhattacharya et.  al.            Expires April 9 1999             [Page xlv]