Internet Engineering Task Force R. Pereira, TimeStep Corp. IP Security Working Group P. Bhattacharya, IBM Corp. Internet Draft Expires in six months February 19, 1998 IPSec Policy Data Model Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSECond) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document presents a data model for IPSec policy based on ISAKMP. R. Pereira, P. Bhattacharya [Page 1] Internet Draft IPSec Policy Data Model February, 98 Table of Contents 1. Introduction...................................................2 1.1. Specification of Requirements..............................2 2. Data Model.....................................................2 2.1. ISAKMP Model...............................................3 2.2. IPSec Model................................................4 3. Security Considerations........................................7 4. References.....................................................7 5. Editors' Addresses.............................................8 1. Introduction The original intent of this document was to present a flexible, extensible and interoperable IPSec policy model that would be used by all IPSec compliant devices. This version of this document represents a scaled down effort of that original goal. This is due to many reasons, most notably the size of such an undertaking and the number of equally correct policy paradigms that IPSec can be molded into. The authors hope that this base IPSec data model will provide implementers sufficient information on the base IPSec negotiation mechanism that they can create an Enterprise policy architecture with the correct IPSec model. It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Atkinso95] and "IP Security Document Roadmap" [Thayer97] documents as well as all other referenced IPSec documents. 1.1. Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97]. 2. Data Model To understand IPSec, the reader must realize that there really exists two different policy areas; one for the ISAKMP security association and one for the actual IPSec (ESP/AH) security association. While the ISAKMP SA relies on the two negotiating peers, the IPSec SA will rely on the hosts actually being protected, which in many cases are the same as the negotiating peers (client to client). R. Pereira, P. Bhattacharya [Page 2] Internet Draft IPSec Policy Data Model February, 98 The current version of this document does not try to represent objects on the network (gateways, firewalls, routers, workstations, ...) and their relationship to these data models. This work might be in future versions of this document, but it is foreseeable that most organizations will require different network security policy architectures. The following data models are represented in ASN.1 notation merely for clarity and is not intended to imply any preference for ASN.1 based policy mechanisms however, a LDAP schema will be added to future versions of this document. 2.1. ISAKMP Model The ISAKMP SA protects the two negotiating peers while they are communicating with ISAKMP. The specification below allows for such examples as; '(DES MD5) or (DES SHA)' IsakmpDescriptor ::= SEQUENCE { exchange ENUMERATED { MainMode, AggressiveMode } OPTIONAL, proposal SEQUENCE OF IsakmpProposal } o The main ISAKMP object mainly includes proposals, but also includes which exchange to utilize. AggressiveMode does not hide the identity of the negotiating peers, while MainMode does. Please refer to [Harkins98] for a more complete reference to both of these two exchange modes. The exchange mode MAY not be included in this object since it MAY instead depend on the peers. o The proposals are all taken as logical ORs when presented together. R. Pereira, P. Bhattacharya [Page 3] Internet Draft IPSec Policy Data Model February, 98 IsakmpProposal ::= SEQUENCE { cipher IsakmpCipherAlg, keylength INTEGER OPTIONAL, hash HashAlg, group INTEGER OPTIONAL, expiry Expiry } o The keylength attribute is only valid when the cipher algorithm is CAST, RC5 or Blowfish. o The default for the group attribute is 1. HashAlg ::= ENUMERATED { md5, sha1, tiger } o The hash algorithm values are specified in [Harkins98]. IsakmpCipherAlg ::= ENUMERATED { des, idea, blowfish, rc5, des3, cast } o The cipher algorithm values are specified in [Harkins98]. Expiry ::= SEQUENCE { seconds INTEGER OPTIONAL, kilobytes INTEGER OPTIONAL } 2.2. IPSec Model The IPSec SA(s) protects the actual IP traffic between two systems. IPSec allows for security gateways (firewalls, routers or edge devices, ...) to proxy on behalf of systems behind them so that the R. Pereira, P. Bhattacharya [Page 4] Internet Draft IPSec Policy Data Model February, 98 negotiating system may not be the end-system. Thus rules based on IpsecDescriptor SHOULD be referenced by the actual end-systems being protected. Additionally, rules MAY also be referenced by either edge devices proxing on their behalf. The specification below allows for such examples as; '(ESP (DES HMAC MD5) OR (DES HMAC SHA)) OR ((ESP DES) AND (AH (HMAC MD5) OR (HMAC SHA)))' IpsecDescriptor ::= SEQUENCE { pfs BOOLEAN, proposal SEQUENCE OF IpsecProposal } o The Perfect Forward Secrecy (pfs) attribute is situated in the IPSec object and not in the ISAKMP object since this attribute is used in QuickMode (phase 2) for the initial IPSec SA and for subsequent rekeyed SAs. o The proposals are all taken as logical ORs when presented together. IpsecProposal ::= SEQUENCE OF { protectionSuite IpsecSuite } o The protectionSuite attributes are all taken as logical ANDs when presented together thus allowing for multiple protocols to be negotiated together. IpsecSuite ::= CHOICE { espProtocol SEQUENCE OF EspProposal, ahProtocol SEQUENCE OF AhProposal, compProtocol SEQUENCE OF IpcompProposal } o The IpsecSuite represents one of three possible protocol types. ESP allows for confidentiality and integrity/authentication, AH only allows for integrity/authentication and IPComp allows for compression. R. Pereira, P. Bhattacharya [Page 5] Internet Draft IPSec Policy Data Model February, 98 EspProposal ::= SEQUENCE { cipher IpsecCipherAlg, keylength INTEGER OPTIONAL, keyrounds INTEGER OPTIONAL, integrity IntegrityAlg OPTIONAL, group INTEGER OPTIONAL, expiry Expiry OPTIONAL } o The keylength attribute MUST only be present when the cipher algorithm is either CAST, RC5, or blowfish. o Key rounds is currently not defined for any cipher algorithm, but if a cipher algorithm is specified in the future that utilizes key rounds, then this attribute MAY be present. o The group attribute defaults to 1 and SHOULD only be present if the PFS attribute is TRUE. AhProposal ::= SEQUENCE { integrity IntegrityAlg, group INTEGER OPTIONAL, expiry Expiry OPTIONAL } o The group attribute defaults to 1 and SHOULD only be present if the PFS attribute is TRUE. IpcompProposal ::= SEQUENCE { compression CompressionAlg, expiry Expiry OPTIONAL } CompressionAlg ::= ENUMERATED { oui, deflate, lzs, v42bis } o The compression algorithm values are specified in [Piper98]. R. Pereira, P. Bhattacharya [Page 6] Internet Draft IPSec Policy Data Model February, 98 IntegrityAlg ::= ENUMERATED { hmacMd5, hmacSha1, hmacDes, keyedMd5, hmacRipem } o The integrity algorithm values are specified in [Piper98]. IpsecCipherAlg ::= ENUMERATED { none, rfc1829-iv64, des, des3, rc5, idea, cast, blowfish, 3idea, rfc1829-iv32, rc4 } o The cipher algorithm values are specified in [Piper98]. 3. Security Considerations This draft merely presents a data model of the IPSec documents. All security considerations within those actual specification MUST be considered previously to implementing a policy architecture. 4. References [Atkinso95] R. Atkinson, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-arch-sec-01 [Bradner97] S. Bradner, "Key words for use in RFCs to indicate Requirement Levels", RFC2119 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol", draft-ietf-ipsec-isakmp-08 R. Pereira, P. Bhattacharya [Page 7] Internet Draft IPSec Policy Data Model February, 98 [Harkins98] D. Harkins, "The Resolution of ISAKMP and Oakley", draft-ietf-ipsec-isakmp-oakley-06 [Droms97] R. Droms, "Dynamic Host Configuration Protocol", RFC2131 [Radius97] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC2138 [Ldap97] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC2251 [Keromy98] A. Keromytis, N. Provos, "The Use of HMAC-RIPEMD-160-96 within ESP and AH", draft-ietf-ipsec-auth-hmac-ripemd- 160-96-01.txt [Piper98] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", draft-ietf-ipsec-ipsec-doi- 07.txt 5. Editors' Addresses Roy Pereira rpereira@timestep.com TimeStep Corporation +1 (613) 599-3610 x 4808 Partha Bhattacharya IBM Corporation partha@watson.ibm.com +1 (919) 863-7981 The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs: Robert Moskowitz rgm@icsa.net International Computer Security Association Theodore Y. Ts'o tytso@MIT.EDU Massachusetts Institute of Technology R. Pereira, P. Bhattacharya [Page 8]