[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSec Policy Model draft
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
<draft-ietf-ipsec-policy-model-01.txt>
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]
Follow-Ups: