Internet Engineering Task Force Jamie Jason
INTERNET DRAFT Intel Coroporation
9-March-2000
IPsec Configuration Policy Model
draft-ietf-ipsp-config-policy-model-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document presents an object-oriented model of low-level IPsec
policy designed to:
o facilitate agreement about the content and semantics of IPsec
policy
o enable derivations of task-specific representations of IPsec
policy such as storage schema, distribution representations,
and policy specification languages used to configure IPsec-
enabled endpoints
The schema described in this document models the IKE phase one
parameters as described in [1] and the IKE phase two parameters for
the IPsec Domain of Interpretation as described in [2, 3, 4, 5].
Jason [Page 1]
Internet Draft IPsec Configuration Policy Model March 2000
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
1. Introduction....................................................4
2. UML Conventions.................................................4
3. Endpoint Classes................................................6
3.1. The Class Endpoint............................................6
3.2. The Class FQDNEndpoint........................................6
3.3. The Class IPv4Endpoint........................................6
3.4. The Class IPv6Endpoint........................................7
4. IPsec Policy Classes............................................8
4.1. The Class IPsecPolicyList.....................................9
4.2. The Class IPsecPolicy.........................................9
4.3. The Class IPInterface.........................................9
5. IPsec Rule Classes.............................................10
5.1. The Class SecurityAssociationRule............................10
6. IPSec Condition Classes........................................11
6.1. The Class SecurityAssociationCondition.......................11
6.2. The Class SecurityAssociationConditionExpression.............12
7. IPSec Filter Classes...........................................13
7.1. The Class SecurityAssociationFilter..........................13
7.2. The Class PortFilter.........................................14
7.3. The Class PortRangeFilter....................................14
7.4. The Class ProtocolFilter.....................................14
7.5. The Class AddressFilter......................................15
7.6. The Class EndpointFilter.....................................15
7.7. The Class IPv4RangeFilter....................................15
7.8. The Class IPv6RangeFilter....................................16
8. IKE and IPsec Action Classes...................................17
8.1. The Class SecurityAssociationAction..........................18
8.2. The Class IKEAction..........................................19
8.3. The Class IPsecAction........................................20
8.4. The Class IPsecTransportAction...............................20
8.5. The Class IPsecTunnelAction..................................21
8.6. The Class IPsecBypassAction..................................21
8.6. The Class IPsecDiscardAction.................................21
9. IKE and IPsec Proposal Classes.................................21
9.1. The Class SecurityAssociationProposal........................22
9.2. The Class IKEProposal........................................22
9.3. The Class IPsecProposal......................................23
9.4. The Class IPsecTransform.....................................24
9.5. The Class ESPTransform.......................................24
9.6. The Class AHTransform........................................25
9.7. The Class IPCompTransform....................................25
10. Diffie-Hellman Classes........................................26
10.1. The Class DiffieHellmanGroup................................27
10.2. The Class NewGroupInfo......................................27
10.3. The Class NewMODPGroupInfo..................................27
10.4. The Class NewECGroupInfo....................................27
10.5. The Class NewEC2NGroupInfo..................................28
10.6. The Class NewECPGroupInfo...................................28
Jason Expires September 2000 [Page 2]
Internet Draft IPsec Configuration Policy Model March 2000
11. Security Considerations.......................................28
12. Intellectual Property.........................................28
13. Acknowledgments...............................................29
14. References....................................................29
15. Disclaimer....................................................30
16. Author's Address..............................................30
17. Full Copyright Statement......................................30
Jason Expires September 2000 [Page 3]
Internet Draft IPsec Configuration Policy Model March 2000
1. Introduction
Internet Protocol security (IPsec) policy may assume a variety of
forms as it travels from storage to distribution point to decision
point. At each step, it needs to be represented in a way that is
convenient for the current task. For example, the policy could
exist as, but is not limited to:
o a Lightweight Directory Access Protocol (LDAP) [6] schema in a
directory
o an on-the-wire representation over a transport protocol like the
Common Object Policy Service (COPS) [7]
o a text-based policy specification language [8] suitable for
editing by an administrator
o an Extensible Markup Language (XML) document
Each of these task-specific representations should be derived from a
canonical representation that precisely specifies the content and
semantics of the IPsec policy. The purpose of this document is to
abstract IPsec policy into a task-independent representation that is
not constrained by any particular task-dependent representation.
This document is organized as follows:
o Section 2 provides a quick introduction to the Unified Modeling
Language (UML) graphical notation conventions used in this
document.
o Section 3 defines the endpoint class, a utility class that is
used as a building block for other classes.
o Section 4 defines the IPsec policy and associated classes.
o Section 5 defines the rule class.
o Section 6 defines the condition and condition expression
classes.
o Section 7 defines the filter classes.
o Section 8 defines the IKE and IPsec action classes.
o Section 9 defines the IKE and IPsec proposal classes.
o Section 10 defines the Diffie-Hellman group class.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [9].
2. UML Conventions
Jason Expires September 2000 [Page 4]
Internet Draft IPsec Configuration Policy Model March 2000
For this document, a UML static class diagram was chosen as the
canonical representation for the IPsec policy model. The reason
behind this decision is that UML provides a task-independent way to
model systems. A treatise on the graphical notation used in UML is
beyond the scope of this paper. However, given the use of ASCII
drawing for UML static class diagrams, a description of the
notational conventions used in this document is in order:
o Boxes represent classes, with class names in brackets ([])
representing a virtual class. For example, in the action
classes diagram, IKEAction is a concrete class while
SecurityAssociationAction is a virtual class.
o A line that terminates with a "o" denotes aggregation.
Aggregation denotes classes with independent lifetimes. An
aggregated object exists independently of the object that
references it. For example, in the action classes diagram a
SecurityAssocationProposal object exists independently of the
SecurityAssociationAction object which references it.
o A line that terminates with an "x" denotes composition.
Composition denotes classes with coincident lifetimes. This
implies that the lifetime of the contained object is the same as
the object that contains it.
o Next to a line appears a multiplicity. Multiplicities indicate
the number of objects contained (or referenced) as well as the
number of object that can contain (or reference) a particular
object. The multiplicity may be:
- a range in the form "lower bound..upper bound" indicating the
minimum and maximum number of objects. For example, in the
action classes diagram, an IPsecAction may contain either 0 or 1
DiffieHellmanGroup objects(essentially noting that the
DiffieHellmanGroup is optional).
- a number that indicates the exact number of objects. For
example, in the proposal classes diagram, an IKEProposal has 1
and only 1 DiffieHellmanGroup. Using a number is equivalent to
number..number.
- an asterisk indicating any number of objects, including zero.
For example, in the action classes diagram, a
SecurityAssociationProposal object may be referenced by 0 to n
SecurityAssociationAction objects. Using an asterisk is
equivalent to 0..n.
- the letter n indicating from 1 to many. For example, in the
action classes diagram, a SecurityAssociationAction references 1
to many SecurityAssociationProposals. Using the letter n is
equivalent to 1..n.
o A line that terminates with an arrow (<, , ^, v) denotes
generalization (inheritance) with the arrow pointing to the
parent class. For example, in the action classes diagram the
SecurityAssociationAction class is a generalization of the
IKEAction class (or said another way, the IKEAction class
derives from the SecurityAssociationAction class).
o Occasionally there may be some text, or a reference to some
text, enclosed by braces ({}). This indicates a constraint.
Constraints are used to constrain the meaning of diagram so that
Jason Expires September 2000 [Page 5]
Internet Draft IPsec Configuration Policy Model March 2000
a diagram does not provide the ability to define something that
does not make sense. For example, in the action classes diagram
there is a constraint placed upon the DiffieHellmanGroup class
such that it is only used if the IPsecAction specifies the user
of Perfect Forward Secrecy.
It should be noted that the UML static class diagram presented is a
conceptual view of IPsec policy designed to aid in understanding.
It does not necessarily get translated class for class into another
representation. For example, an LDAP implementation may flatten out
the representation to fewer classes (because of the inefficiency of
following references).
3. Endpoint Classes
An endpoint is an abstraction used to represent an IP address or
hostname. This class is used as a building block in further
classes.
+----------+
| |
|[Endpoint]|
| |
+----------+
^
|
+---------------------------+--------------------------+
| | |
+------------+ +------------+ +------------+
| | | | | |
|FQDNEndpoint| |IPv4Endpoint| |IPv6Endpoint|
| | | | | |
+------------+ +------------+ +------------+
3.1. The Class Endpoint
The Endpoint class is used as an abstract base class from which
concrete endpoint classes are expected to derive from.
3.2. The Class FQDNEndpoint
The FQDNEndpoint class is used to represent endpoints that can be
expressed using a DNS name. It contains the following attribute:
NAME name
DESCRIPTION Either a fully-qualified or wild-carded (partially or
fully) domain name.
TYPE string
VALUE MAY either be fully-qualified (for example,
runner.jf.intel.com) or wild-carded (for example,
*.intel.com).
3.3. The Class IPv4Endpoint
Jason Expires September 2000 [Page 6]
Internet Draft IPsec Configuration Policy Model March 2000
The IPv4Endpoint class is used to represent endpoints that can be
expressed using an IPv4 address. It contains the following
attribute:
NAME address
DESCRIPTION The IPv4 address.
TYPE unsigned 32-bit integer
VALUE 0x00000000 (i.e., 0.0.0.0) - used to specify any IP
address (i.e., a totally wild-carded address or "*").
Any other value specifies an IPv4 address.
3.4. The Class IPv6Endpoint
The IPv6Endpoint class is used to represent endpoints that can be
expressed using an IPv6 address. It contains the following
attribute:
NAME address
DESCRIPTION The IPv6 address.
TYPE octet[16]
VALUE all zero's (i.e., 0:0:0:0:0:0:0:0) - used to specify
any IP address (i.e., a totally wild-carded address or
"*"). Any other value specifies an IPv6 address.
Jason Expires September 2000 [Page 7]
Internet Draft IPsec Configuration Policy Model March 2000
4. IPsec Policy Classes
The IPsec policy classes represent the set of policies that are
contained on a system. In addition, they indicate the active
policies as well as associate a policy with a particular interface
on a system
+---------------+
| |
|IPsecPolicyList|
| |
+---------------+
* o
|
(a)|
|
* |
+-----------+ +-----------+
| |* (b) *| |
|IPsecPolicy|o-----------|IPInterface|
| | {1} | |
+-----------+ +-----------+
1 x x 1 1 x
| | |
(c)|{2} {3}|(d) (e)|{4}
| | |
* | | * 1 |
+----------------------+ +----------+
| | | |
|SecurityAssocationRule| |[Endpoint]|
| | | |
+----------------------+ +----------+
(a) Policies
(b) TargetedInterface
(c) IKERules
(d) IPsecRules
(e) Identity
{1} 1. If the policy is marked as enabled, then the IPsecPolicy
object MUST reference an IPInterface object.
2. For each interface, there is only one IPsec policy marked
as enabled.
{2} IKE rules are ordered and are considered logically ORed. Rule
search will stop once a rule that matches the input criteria is
found.
{3} IPsec rules are ordered and are considered logically ORed.
Rule search will stop once a rule that matches the input
criteria is found.
{4} If the endpoint type is an FQDN, then the DNS name MUST be
fully-qualifed (i.e., no wild-card values allowed).
If the endpoint type is an IPv4 or IPv6 address, then the
address value MUST NOT be the wild-card address.
Jason Expires September 2000 [Page 8]
Internet Draft IPsec Configuration Policy Model March 2000
4.1. The Class IPsecPolicyList
The IPsecPolicyList class is a container for all of the policies on
a particular system. It contains the following reference:
NAME Policies
DESCRIPTION The policies installed on a particular system. Note
that there is a distinction between a policy being
installed on a system and actually being actively
enforced (see the IPsecPolicy class).
Note: an IPsecPolicyList MAY contain no policies. Additionally, a
policy MAY be defined which is not in any policy list. The latter
case is only relevant for a management station - in other words, an
IPsec policy has been created but it has not yet been targeted to a
system.
4.2. The Class IPsecPolicy
The IPsecPolicy class is a container for all of the rules used to
enforce the policy. It contains the following attribute/references:
NAME enabled
DESCRIPTION Indicates whether or not the policy is enabled (i.e.,
is actively being enforced). As stated in the
constraint {1}, if the policy is enabled, it MUST be
associated with a particular interface on the system.
This allows for different policies to be enforced on
different interfaces.
TYPE boolean
VALUE true - policy is currently enabled
false - policy is currently disabled
NAME TargetedInterface
DESCRIPTION The interface on the system for which this policy is to
be enforced. As stated in the constraint {1}, for each
interface there is only one policy enabled at any one
given time.
NAME IKERules
DESCRIPTION The rules which govern when and how to perform IKE
phase 1 negotiation. These rules are an ordered list
and are logically ORed. When processing the rules, the
first rule matched is the one used.
NAME IPsecRules
DESCRIPTION The rules which govern when and how to perform IKE
phase 2 negotiation. These rules are an ordered list
and are logically ORed. When processing the rules, the
first rule matched is the one used.
4.3. The Class IPInterface
Jason Expires September 2000 [Page 9]
Internet Draft IPsec Configuration Policy Model March 2000
The IPInterface class is used to represent an interface on the
system. It contains the following reference:
NAME Identity
DESCRIPTION Indicates the IP address or DNS name assigned to the
interface. No wild-card values are allowed for the
endpoint object.
5. IPsec Rule Classes
The IPsec rule class is used to associate a condition with the
action which is to be performed when the condition evaluates to
true.
+-----------------------+
| |
|SecurityAssociationRule|
| |
+-----------------------+
* o o *
| |
+----------+ +-----------+
| (a) (b) |
1 | | 1
+----------------------------+ +---------------------------+
| | | |
|SecurityAssociationCondition| |[SecurityAssociationAction]|
| | | |
+----------------------------+ +---------------------------+
(a) Condition
(b) Action
5.1. The Class SecurityAssociationRule
The SecurityAssociationRule class is used to associate a condition
with the IKE/IPsec action information that is to be used during the
negotiation. It contains the following attribute/references:
NAME enabled
DESCRIPTION Indicates whether or not the rule is enabled.
TYPE boolean
VALUE true - rule is currently enabled
false - rule is currently disabled
NAME Condition
DESCRIPTION The condition, when evaluated against the given input,
that MUST evaluate to true in order for the associated
action to be performed.
NAME Action
DESCRIPTION The security association negotiation parameters to use
when the associated condition evaluates to true.
Jason Expires September 2000 [Page 10]
Internet Draft IPsec Configuration Policy Model March 2000
6. IPSec Condition Classes
The condition class is used to determine when the associated IKE or
IPsec action is to be performed.
+----------------------------+
| |
|SecurityAssociationCondition|
| |
+----------------------------+
1 x
|
{1}|(a)
|
* |
+--------------------------------------+
| |
|SecurityAssociationConditionExpression|
| |
+--------------------------------------+
1 |
|
{2}|(b)
|
* |
+---------------------------+
| |
|[SecurityAssociationFilter]|
| |
+---------------------------+
(a) Expressions
(b) Filters
{1} If using disjunctive normal form (DNF), each expression is
logically ORed. If using conjunctive normal form (CNF), each
expression is logically ANDed.
{2} If using DNF, each filter is logically ANDed. If using CNF,
each filter is logically ORed.
6.1. The Class SecurityAssociationCondition
The SecurityAssociationCondition class specifies the criteria that
is applied to the input information to determine if a particular
condition is met. It contains the following attributes/references:
NAME negated
DESCRIPTION Indicates whether or not the result of the rule
evaluation is to be negated.
TYPE boolean
VALUE true - condition evaluation result is to be negated
Jason Expires September 2000 [Page 11]
Internet Draft IPsec Configuration Policy Model March 2000
false - condition evaluation result is not to be
negated
NAME useDNF
DESCRIPTION Indicates whether or not the rule is specified in DNF
or CNF form.
TYPE boolean
VALUE true - condition is expressed as DNF. The expressions
within the condition are logically ORed. The filters
within an expression are logically ANDed.
false - condition is expressed as CNF. The expressions
within the condition are logically ANDed. The filters
within an expression are logically ORed.
6.2. The Class SecurityAssociationConditionExpression
The SecurityAssociationConditionExpression class is used to combine
several filters, which together constitute one logical expression.
It contains the following reference:
NAME Filters
DESCRIPTION The set of filters, which combined, are used to
represent the expression. When using DNF, these
filters are logically ANDed. When using CNF, these
filters are logically ORed.
Jason Expires September 2000 [Page 12]
Internet Draft IPsec Configuration Policy Model March 2000
7. IPSec Filter Classes
The filter classes are used to specify individual criteria which
MUST be met before a condition will evaluate to true.
+---------------------------+
| |
|[SecurityAssociationFilter]|
| |
+---------------------------+
^
|
+----------------+---------+-------+-----------------+
{1}| | | |
+-------------+ +----------+ +---------------+ +--------------+
| | | | | | | |
|AddressFilter| |PortFilter| |PortRangeFilter| |ProtocolFilter|
| | | | | | | |
+-------------+ +----------+ +---------------+ +--------------+
^
|
+----------------------+---------------------+
| | |
+--------------+ +---------------+ +---------------+
| | | | | |
|EndpointFilter| |IPv4RangeFilter| |IPv6RangeFilter|
| | | | | |
+--------------+ +---------------+ +---------------+
1 x
|
(a)|
|
1 |
+----------+
| |
|[Endpoint]|
| |
+----------+
(a) Identity
{1} When the rule is for an IKE phase one negotiation, the
AddressFilter is the only type of filter allowed.
7.1. The Class SecurityAssociationFilter
The SecurityAssociationFilter class is used as an abstract base
class from which all concrete filter class are expected to derive
from. It contains the following attribute:
NAME negated
DESCRIPTION Indicates whether or not the result of the filter
evaluation is to be negated.
Jason Expires September 2000 [Page 13]
Internet Draft IPsec Configuration Policy Model March 2000
TYPE boolean
VALUE true - filter evaluation is to be negated
false - filter evaluation is not to be negated
7.2. The Class PortFilter
The PortFilter class specifies a filter that is based upon a single
port value. It contains the following attributes:
NAME applyToSource
DESCRIPTION Indicates whether or not the port specified is to be
interpreted as a source port or a destination port.
TYPE boolean
VALUE true - the port specified is to be interpreted as a
source port
false - the port specified is to be interpreted as a
destination port
NAME port
DESCRIPTION Specifies the port value.
TYPE unsigned 16-bit integer
VALUE 0 - wild-card port (i.e., any port matches). Any other
value specifies a specific port.
7.3. The Class PortRangeFilter
The PortRangeFilter class specifies a filter that is based upon a
range of port values. The port range is to be interpreted as
inclusive. It contains the following attributes:
NAME applyToSource
DESCRIPTION Indicates whether or not the port specified is to be
interpreted as a source port range or a destination
port range.
TYPE boolean
VALUE true - the port range specified is to be interpreted as
a source port range
false - the port range specified is to be interpreted
as a destination port range
NAME firstPort
DESCRIPTION Specifies the first port in the range.
TYPE unsigned 16-bit integer
NAME lastPort
DESCRIPTION Specifies the last port in the range.
TYPE unsigned 16-bit integer
VALUE The lastPort attribute value MUST be greater than or
equal to the firstPort attribute value.
7.4. The Class ProtocolFilter
Jason Expires September 2000 [Page 14]
Internet Draft IPsec Configuration Policy Model March 2000
The ProtocolFilter class specifies a filter that is based upon the
IP protocol. It contains the following attribute:
NAME protocol
DESCRIPTION Specifies the IP protocol value.
TYPE unsigned 8-bit integer
VALUE 0 - wild-card protocol (i.e., any protocol). Any other
value specifies a specific protocol.
Note: if using DNF, it does not make sense to use a PortFilter or
PortRangeFilter when using a ProtocolFilter that is not either UDP
or TCP.
7.5. The Class AddressFilter
The AddressFilter class is used to represent filters which use a
system's address or DNS name as a filter. It is used as an abstract
base class from which specific address-based filters will be
derived. The address filters are always used to specify the
address/hostname of the destination machine. The reason is that the
association of a policy with a particular interface implies the
source address/hostname - one could look at the policy to interface
mapping as another type of filter.
Note: for IKE rules, these are the only filter type allowed.
7.6. The Class EndpointFilter
The EndpointFilter class is used to represent a filter that
specifies an individual interface on one system. It is used to
specify an FQDN, an IPv4 address, or an IPv6 address. It contains
the following reference:
NAME Identity
DESCRIPTION Specifies the FQDN or IP address to use for the filter.
The value MAY be wild-carded (see the Endpoint class
description).
7.7. The Class IPv4RangeFilter
The IPv4RangeFilter is used to represent a filter that specifies a
range of IPv4 address. The range is to be interpreted as inclusive.
It contains the following attributes:
NAME firstAddress
DESCRIPTION Specifies the first address in the range.
TYPE unsigned 32-bit value
NAME lastAddress
DESCRIPTION Specifies the last address in the range.
TYPE unsigned 32-bit value
VALUE The lastAddress attribute value MUST be greater than or
equal to the firstAddress attribute value.
Jason Expires September 2000 [Page 15]
Internet Draft IPsec Configuration Policy Model March 2000
7.8. The Class IPv6RangeFilter
The IPv6RangeFilter is used to represent a filter that specifies a
range of IPv6 address. The range is to be interpreted as inclusive.
It contains the following attributes:
NAME firstAddress
DESCRIPTION Specifies the first address in the range.
TYPE octet[16]
NAME lastAddress
DESCRIPTION Specifies the last address in the range.
TYPE octet[16]
VALUE The lastAddress attribute value MUST be greater than or
equal to the firstAddress attribute value.
Jason Expires September 2000 [Page 16]
Internet Draft IPsec Configuration Policy Model March 2000
8. IKE and IPsec Action Classes
An action is a set of proposals combined with the security
association level information that is used to protect a particular
flow.
+---------------------------+
| |
|[SecurityAssociationAction]|
| |o---+
+---------------------------+* |
^ (a)|{1}
| n|
| +-----------------------------+
| | |
| |[SecurityAssociationProposal]|
| | |
| +-----------------------------+
|
+---------+ |
| | |
|IKEAction|---+
| | |
+---------+ |
|
+-----------+ | +------------------+
| |---+ | |
|IPsecAction| (b) 0..1|DiffieHellmanGroup|
| |o--------------| |
+-----------+* {2} +------------------+
^
|
+--------+------------+-----------+------------+
| | | |
+--------------------+ +-----------------+ | +-----------------+
| | | | | | |
|IPsecTransportAction| |IPsecTunnelAction| | |IPsecBypassAction|
| | | | | | |
+--------------------+ +-----------------+ | +-----------------+
1 x |
| |
(c)|{3} +------------+
| |
+----------+ +------------------+
| | | |
|[Endpoint]| |IPsecDiscardAction|
| | | |
+----------+ +------------------+
(a) Proposals
(b) IPsecGroup
(c) RemoteGateway
Jason Expires September 2000 [Page 17]
Internet Draft IPsec Configuration Policy Model March 2000
{1} 1. For an IKEAction object, these MUST be IKEPropsal objects.
For an IPsecAction object, these MUST be IPsec Action objects.
2. SecurityAssociationProposal objects are ordered from most
preferable to least preferable and are logically ORed. The
mechanism by which ordering is accomplished is dependent upon
the specific derivation of the IPsec schema.
{2} If not using Perfect Forward Secrecy (PFS), then the
DiffieHellmanGroup object either does not exist or is ignored.
Otherwise (PFS is used) if the DiffieHellmanGroup object is not
present, then the Diffie-Hellman Group from Phase 1 will be
used for Phase 2. Otherwise, use the DiffieHellmanGroup
object.
{3} If the endpoint type is an FQDN, then the DNS name MUST be
fully-qualifed (i.e., no wild-card values allowed).
If the endpoint type is an IPv4 or IPv6 address, then the
address MUST NOT be the wild-card value.
8.1. The Class SecurityAssociationAction
The SecurityAssociationAction class contains the parameters that are
common between the IKE and IPsec action classes. It contains the
following attributes/references:
NAME refreshThresholdSeconds
DESCRIPTION Specifies the percentage of expiration (in other words,
the refresh threshold) of an established SA's seconds
lifetime at which to begin renegotiation of the SA.
TYPE integer
VALUE Valid values are in the range 1 to 100 inclusive. A
value of 100 means that renegotiation does not occur
until the seconds lifetime value has expired.
refreshThresholdSeconds is not a negotiated parameter.
NAME refreshThresholdKilobytes
DESCRIPTION Specifies the percentage of expiration of an
established SA's kilobyte lifetime at which to begin
renegotiation of the SA.
TYPE integer
VALUE Valid values are in the range 1 to 100 inclusive. A
value of 100 means that renegotiation does not occur
until the kilobyte lifetime value has expired.
refreshThresholdKilobytes is not a negotiated parameter.
NAME minLifetimeSeconds
DESCRIPTION Specifies the minimum SA seconds lifetime that will be
accepted from a peer while negotiating an SA based upon
this action. The purpose of this value is to prevent
denial-of-service attacks in which a peer can select an
arbitrarily low seconds lifetime, causing the IKE
server to perform renegotiations with correspondingly
expensive Diffie-Hellman calculations.
Jason Expires September 2000 [Page 18]
Internet Draft IPsec Configuration Policy Model March 2000
TYPE unsigned 32-bit integer
VALUE 0 - indicates that there is no minimum lifetime
enforced.
Any other value specifies a required minimum seconds
lifetime.
minLifetimeSeconds is not a negotiated parameter.
NAME minLifetimeKilobytes
DESCRIPTION Specifies the minimum kilobyte lifetime that will be
accepted from a negotiating peer while negotiating an
SA based upon this action. The purpose of this value
is to prevent denial-of-service attacks in which a peer
can select an arbitrarily low kilobyte lifetime,
causing the IKE server to perform renegotiations with
correspondingly expensive Diffie-Hellman calculations.
TYPE unsigned 32-bit integer
VALUE 0 - indicates that there is no minimum lifetime
enforced.
Any other value specifies a required minimum kilobyte
lifetime.
minLifetimeKilobytes is not a negotiated parameter.
NAME trafficIdleTime
DESCRIPTION Specifies the amount of time in seconds an SA,
negotiated using the containing action object, may
remain idle (in other words, no traffic protected by
the SA) before it is deleted.
TYPE unsigned 32-bit integer
VALUE 0 - there is no idle time detection. In other words,
the expiration of the SA is solely dependent upon the
expiration of one of the lifetime values.
Any other value specifies the number of seconds the SA
may remain idle before it can be forcibly expired.
trafficIdleTime is not a negotiated parameter.
NAME Proposals
DESCRIPTION Specifies a logically ORed set of proposals, ORDERED
from most preferable to least prefereable, which are
used during negotiation of the SA. If the action is an
IKEAction, then the set will contain IKEProposal
objects. If the action is an IPsecAction, then the set
will contain IPsecProposal objects. A
SecurityAssociationAction object will reference one to
many SecurityAssociationProposal objects. A
SecurityAssociationProposal object MAY be referenced by
zero to many SecurityAssociationAction objects. See
section 9 for a description of the
SecurityAssociationProposal and derived classes.
8.2. The Class IKEAction
Jason Expires September 2000 [Page 19]
Internet Draft IPsec Configuration Policy Model March 2000
IKEAction is a specialization of the SecurityAssociationAction class
and specifies the parameters unique to an IKE action. It contains
the following attributes:
NAME exchangeMode
DESCRIPTION Specifies the negotiation mode that the IKE server will
use for phase one.
TYPE unsigned 16-bit integer
VALUE 1 - base mode
2 - main mode
4 - aggressive mode
NAME refreshThresholdDerivedKeys
DESCRIPTION Specifies the percentage of expiration of an
established IKE SA's derived keys lifetime at which to
begin renegotiation of the SA.
TYPE integer
VALUE Valid values are in the range 1 to 100 inclusive. A
value of 100 means that renegotiation does not occur
until the derived key lifetime value has expired.
refreshThresholdDerivedKeys is not a negotiated parameter.
8.3. The Class IPsecAction
IPsecAction is a specialization of the SecurityAssociationAction
class and specifies the parameters unique to an IPsec action. It
contains the following attributes/references:
NAME usePfs
DESCRIPTION Specifies whether or not PFS should be used when
negotiating the phase two IPsec SA.
TYPE boolean
VALUE true
false
NAME IPsecGroup
DESCRIPTION If PFS should be used during IKE phase two, this
specifies the Diffie-Hellman group to use. The
DiffieHellmanGroup class is described in section 10.
DEFAULT Since an IPsecAction object MAY optionally contain a
IPsecGroup object, absence of one when using PFS
indicates that the IKE phase two negotiation should use
the same Diffie-Hellman group that was agreed upon
during the IKE phase one negotiation.
8.4. The Class IPsecTransportAction
IPsecTransportAction is a specialization of IPsecAction, but does
not add any attributes. It is used to signify that the phase two
action will be for the negotiation of an IPsec transport mode SA.
Jason Expires September 2000 [Page 20]
Internet Draft IPsec Configuration Policy Model March 2000
8.5. The Class IPsecTunnelAction
IPsecTunnelAction is a specialization of IPsecAction that is used to
signify that the phase two action will be for the negotiation of an
IPsec tunnel mode SA. It contains the following reference:
NAME RemoteGateway
DESCRIPTION The identity of the point where the tunnel terminates
on the remote gateway.
Note: since a particular IPsec policy is directly associated with a
particular interface in the system, the local gateway identity can
be implicitly determined from this information.
8.6. The Class IPsecBypassAction
IPsecBypassAction is a specialization of IPsecAction, but does not
add any attributes. It is used to signify that the traffic is to be
allowed to pass in the clear.
8.6. The Class IPsecDiscardAction
IPsecDiscardAction is a specialization of IPsecAction, but does not
add any attributes. It is used to signify that the traffic should
be denied.
9. IKE and IPsec Proposal Classes
A proposal contains the security parameters that will be used during
the IKE phase one and two negotiations.
+-----------------------------+
| |
|[SecurityAssociationProposal]|
| |
+-----------------------------+
^
|
+---------------------------+
| |
+-------------+ +-----------+
| | | |
|IPsecProposal| |IKEProposal|
| | | |
+-------------+ +-----------+
* o * o
|(a) |(b)
n | 1 |
+----------------+ +------------------+
| | | |
|[IPsecTransform]| |DiffieHellmanGroup|
| | | |
+----------------+ +------------------+
Jason Expires September 2000 [Page 21]
Internet Draft IPsec Configuration Policy Model March 2000
^
|
+-------------+------------------+
| | |
+------------+ +-----------+ +---------------+
| | | | | |
|ESPTransform| |AHTransform| |IPCompTransform|
| | | | | |
+------------+ +-----------+ +---------------+
(a) Transforms
(b) IkeDhGroup
9.1. The Class SecurityAssociationProposal
The SecurityAssociationProposal class contains the parameters that
are common between the IKE and IPsec proposal classes. It contains
the following attributes:
NAME lifetimeSeconds
DESCRIPTION Specifies the seconds lifetime for this particular
proposal. This value is used when sending this
proposal to the negotiating peer. Additionally, it may
be used, possibly in conjunction with the minimum
seconds lifetime value, when selecting a proposal from
the negotiating peer.
TYPE unsigned 32-bit integer
VALUE 0 - indicates that the lifetime value defaults to 8
hours (28,800 seconds).
NAME lifetimeKilobytes
DESCRIPTION Specifies the kilobyte lifetime for this particular
proposal. This value is used when sending this
proposal to the negotiating peer. Additionally, it may
be used, possibly in conjunction with the minimum
kilobyte lifetime value, when selecting a proposal from
the negotiating peer.
TYPE unsigned 32-bit integer
VALUE 0 - indicates that there is no kilobyte lifetime.
9.2. The Class IKEProposal
IKEProposal is a specialization of the SecurityAssociationProposal
class and specifies the parameters unique to the IKE proposal. It
contains the following attributes/references:
NAME cipherAlgorithm
DESCRIPTION Specifies the encryption algorithm the IKE server will
propose.
TYPE unsigned 16-bit integer
VALUE 1 - DES-CBC
2 - IDEA-CBC
3 - Blowfish-CBC
Jason Expires September 2000 [Page 22]
Internet Draft IPsec Configuration Policy Model March 2000
4 - RC5-R16-B64-CBC
5 - 3DES-CBC
6 - CAST-CBC
NAME hashAlgorithm
DESCRIPTION Specifies the hash algorithm the IKE server will
propose.
TYPE unsigned 16-bit integer
VALUE 1 - MD5
2 - SHA-1
3 - Tiger
NAME authenticationMethod
DESCRIPTION Specifies the authentication method the IKE server will
propose.
TYPE unsigned 16-bit integer
VALUE 1 - Preshared Key
2 - DSS Signatures
3 - RSA Signatures
4 - RSA Encryption
5 - Revised RSA Encryption
6 - El-Gamal Encryption
7 - Revised El-Gamal Encyrption
65001 - Kerberos
NAME lifetimeDerivedKeys
DESCRIPTION Specifies the number of times the IKE phase one key may
be used to derive an IKE phase two key.
TYPE unsigned 32-bit integer
VALUE 0 - indicates that the number of times a IKE phase one
key may be used to derive an IKE phase two key is
limited by the seconds and/or kilobyte lifetimes.
lifetimeDerivedKeys is not a negotiated parameter. Although this
value is not negotiated, it is included with the proposal
information as the value is dependent upon the strength of the
security parameters in the proposal.
NAME prfAlgorithm
DESCRIPTION Specifies the Psuedo-Random Function (PRF) the IKE
server will propose.
TYPE unsigned 16-bit integer
VALUE At this time, there are no negotiable PRFs defined.
NAME IkeDhGroup
DESCRIPTION Specifies the Diffie-Hellman group that the IKE server
will propose. The DiffieHellmanGroup class is defined
in section 10.
9.3. The Class IPsecProposal
Jason Expires September 2000 [Page 23]
Internet Draft IPsec Configuration Policy Model March 2000
IPsecProposal is a specialization of the SecurityAssociationProposal
class and specifies the parameters unique to the IPsec proposal. It
contains the following reference:
NAME Transforms
DESCRIPTION Specifies a set of IPsecTransform objects that
represent the Encapsulating Security Payload (ESP),
Authentication Header (AH), and IP Payload Compression
Protocol (IPComp) parameters that are to used to create
an IPsec proposal. Transforms of the same type are to
be grouped together and logically ORed and the order of
the transforms of the same type MUST be preserved. The
transform groups are to be logically ANDed. For
example, if the proposal had the following set of
transforms {ESP=DES,AH=MD5,ESP=3-DES,ESP=RC5,AH=SHA-1},
the proposal would be ((ESP = DES or 3-DES or RC5) and
(AH = MD5 or SHA-1)). An IPsecProposal object MAY
reference one to many IPsecTransform objects. An
IPsecTransform object MAY be referenced by zero to many
IPsecProposal objects.
9.4. The Class IPsecTransform
The IPsecTransform class contains no properties and exists only for
the purpose of modeling the is-a-kind-of relationship for IPsec
transforms. For example, an ESPTransform is a kind of
IPsecTransform.
9.5. The Class ESPTransform
ESPTransform is a specialization of an IPsecTransform. It specifies
the parameters for one IPSec ESP transform within an IPsec proposal.
It contains the following attributes:
NAME integrityTransformId
DESCRIPTION Specifies the ESP integrity algorithm to propose.
TYPE unsigned 16-bit integer
VALUE 1 - HMAC MD5
2 - HMAC SHA-1
3 - HMAC DES
4 - KPDK
NAME cipherTransformId
DESCRIPTION Specifies the ESP cipher/encryption algorithm to
propose.
TYPE unsigned 16-bit integer
VALUE 1 - DES IV64
2 - DES
3 - 3-DES
4 - RC5
5 - IDEA
6 - CAST
7 - Blowfish
Jason Expires September 2000 [Page 24]
Internet Draft IPsec Configuration Policy Model March 2000
8 - 3-IDEA
9 - DES IV32
10 - RC4
11 - NULL
NAME cipherKeyRounds
DESCRIPTION Specifies the number of key rounds for the ESP cipher
algorithm specified by the attribute cipherTransformId.
TYPE unsigned 16-bit integer
VALUE At this time, there are no cipher key rounds defined
for any IPsec ESP algorithms.
NAME cipherKeyLength
DESCRIPTION Specifies the length of the ESP cipher key, in bits.
If cipherTansformId specifies a cipher with a fixed-
length key, cipherKeyLength is ignored.
TYPE unsigned 16-bit integer
VALUE 0 - the cipher algorithm specified by the
cipherTransformId attribute implies the key length.
Any other value specifies a key length, in bits.
9.6. The Class AHTransform
AHTransform is a specialization of an IPsecTransform. It specifies
the parameters for one AH transform within an IPsec proposal. It
contains the following property:
NAME transformId
DESCRIPTION Specifies the AH hash algorithm to propose.
TYPE unsigned 16-bit integer
VALUE 2 - MD5
3 - SHA-1
4 - DES
9.7. The Class IPCompTransform
IPCompTransform is a specialization of an IPsecTransform. It
specifies the parameters for one IPComp transform within an IPsec
proposal. It contains the following properties:
NAME algorithm
DESCRIPTION Specifies the IPComp compression algorithm to propose.
TYPE unsigned 16-bit integer
VALUE 1 - OUI (privateAlgorithm MUST contain a valid value)
2 - Deflate
3 - LZS
NAME dictionarySize
DESCRIPTION Specifies the dictionary size for the compression
algorithm.
TYPE unsigned 16-bit integer
VALUE 0 - the compression algorithm specified by the
algorithm attribute dictates the dictionary size.
Jason Expires September 2000 [Page 25]
Internet Draft IPsec Configuration Policy Model March 2000
Any other value is to be interpreted in the context of
the compression algorithm.
NAME privateAlgorithm
DESCRIPTION If the algorithm attribute specifies the use of a
proprietary compression transform (OUI = 1), then this
specifies the specific vendor algorithm that will be
used. Otherwise, this value is ignored.
TYPE unsigned 32-bit integer
10. Diffie-Hellman Classes
The Diffie-Hellman classes are used to define the Diffie-Hellman
attributes that are used during phase one (and possibly phase two)
of the IKE negotiation.
+------------------+
| |
|DiffieHellmanGroup|
| |
+------------------+
* o
(a) | {1}
0..1 |
+--------------+
| |
|[NewGroupInfo]|
| |
+--------------+
^
|
+----------------+----------------+
| |
+----------------+ +----------------+
| | | |
|NewMODPGroupInfo| |[NewECGroupInfo]|
| | | |
+----------------+ +----------------+
^
|
+-----------+----------+
| |
+----------------+ +---------------+
| | | |
|NewEC2NGroupInfo| |NewECPGroupInfo|
| | | |
+----------------+ +---------------+
(a) ExplicitGroupInfo
{1} If the Diffie-Hellman Group is a well-known group (or previously
agreed upon private group), then the NewGroupInfo object doesn't
exist (or is ignored).
Jason Expires September 2000 [Page 26]
Internet Draft IPsec Configuration Policy Model March 2000
10.1. The Class DiffieHellmanGroup
DiffieHellmanGroup describes the specific Diffie-Hellman Group that
will be proposed. It contains the following properties:
NAME groupDescription
DESCRIPTION Specifies the Diffie-Hellman Group to propose.
TYPE unsigned 16-bit integer
VALUE 1 - 768-bit MODP group
2 - 1024-bit MODP group
3 - EC2N group on GP[2^155]
4 - EC2N group on GP[2^185]
5 - 1536-bit MODP group
NAME ExplicitGroupInfo
DESCRIPTION Specifies Diffie-Hellman Group information if
groupDescription is not one of the well-known values or
a previously agreed upon private group. If
groupDescription is one of the well-known values or a
previously agreed upon private group, the NewGroupInfo
object will not exist or it is ignored.
10.2. The Class NewGroupInfo
NewGroupInfo is the abstract base class for the concrete new group
information classes. The specific derived class implies the group
type value.
10.3. The Class NewMODPGroupInfo
NewMODPGroupInfo specifies the Diffie-Hellman group information for
a MODP group that is proposed during new group mode. It contains
the following properties:
NAME prime
DESCRIPTION Specifies the prime for the MODP group.
TYPE byte string
NAME generator
DESCRIPTION Specifies the generator for the MODP group.
TYPE byte string
10.4. The Class NewECGroupInfo
NewECGroupInfo is an abstract class that specifies the Diffie-
Hellman group information for an elliptic curve group that is
proposed during new group mode. It contains the following
properties:
NAME polynomial
DESCRIPTION Specifies the polynomial for the elliptic curve group.
TYPE byte string
Jason Expires September 2000 [Page 27]
Internet Draft IPsec Configuration Policy Model March 2000
NAME fieldSize
DESCRIPTION Specifies the field size for the elliptic curve group.
TYPE unsigned 32-bit integer
NAME order
DESCRIPTION Specifies the order for the elliptic curve group.
TYPE unsigned 32-bit integer
NAME generatorOne
DESCRIPTION Specifies generator one for the elliptic curve group.
TYPE byte string
NAME generatorTwo
DESCRIPTION Specifies generator two for the elliptic curve group.
TYPE byte string
NAME curveA
DESCRIPTION Specifies curve A for the elliptic curve group.
TYPE byte string
NAME curveB
DESCRIPTION Specifies curve B for the elliptic curve group.
TYPE byte string
10.5. The Class NewEC2NGroupInfo
NewEC2NGroupInfo is a class that represents a new EC2N group. It
contains no properties and exists only to imply the group type.
10.6. The Class NewECPGroupInfo
NewECPGroupInfo is a class that represents a new ECP group. It
contains no properties and exists only to imply the group type.
11. Security Considerations
This document describes a schema for IPsec policy. It does not
detail security requirements for storage or delivery of said schema.
Storage and delivery security requirements should be detailed in a
comprehensive security policy architecture document.
12. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11.
Jason Expires September 2000 [Page 28]
Internet Draft IPsec Configuration Policy Model March 2000
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
13. Acknowledgments
The author would like to thank Mike Jeronimo, Ylian Saint-Hilaire,
Vic Lortz, and William Dixon for their contributions to this IPsec
policy model.
Additionally, this draft would not have been possible without the
preceding IPsec schema drafts. For that, thanks go out to Rob
Adams, Partha Bhattacharya, William Dixon, Roy Pereira, and Raju
Rajan.
14. References
[1] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[2] Shacham, A., and R. Monsour, R. Pereira, M. Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 2393, August 1998.
[3] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[4] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[5] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[6] Wahl, M., and T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[7] Boyle, J., and R. Cohen, D. Durham, S. Herzog, R. Rajan, A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748,
January 2000. Internet-Draft work in progress.
[8] Condell, M., and C. Lynn, J. Zao, "Security Policy Specification
Language", draft-ietf-ipsec-spsl-01.txt, July 1999. Internet-Draft
work in progress.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Jason Expires September 2000 [Page 29]
Internet Draft IPsec Configuration Policy Model March 2000
15. Disclaimer
The views and specification herein are those of the authors and are
not necessarily those of their employer. The authors and their
employer specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.
16. Author's Address
Jamie Jason
Intel Corporation
MS JF3-206
2111 NE 25th Ave.
Hillsboro, OR 97124
Phone: +1-503-264-9531
Fax: +1-503-264-9428
E-Mail: jamie.jason@intel.com
17. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it maybe copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other then
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING
TASK FORCE DISCLIAMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMAITON
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTEIS OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Jason Expires September 2000 [Page 30]
