Internet Engineering Task Force Jamie Jason INTERNET DRAFT Intel Coroporation 9-March-2000 IPsec Configuration Policy Model draft-jason-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]