INTERNET-DRAFT R. Thayer
N. Doraswamy
April 1997
IPSEC Policy Import/Export Format
<draft-thayer-sec-exp-01.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as ``work
in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.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).
Abstract
Under certain conditions it is necessary to configure hosts
running IP Security [RFC-1825] with security parameters and other
information in an out-of-band manner. This draft defines a file
format that may be used to exchange such information via
removable media or distribution via a web server.
THIS DOCUMENT EXPIRES DECEMBER 1997.
Thayer,Doraswamy [Page 1]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
TABLE OF CONTENTS
STATUS OF THIS MEMO.............................................1
ABSTRACT........................................................1
1.1 TERMS.......................................................5
1.2 REQUIREMENTS TERMINOLOGY....................................5
2. GENERAL FORMATTING...........................................6
2.1 FORMAT OF IDENTIFIER LINE...................................6
2.1 CONFIGURATION LINE FORMATTING RULES.........................7
2.2 KEYWORDS....................................................7
3. BLOCK CONTENTS...............................................8
3.1 CONFIGURATION BLOCK.........................................8
3.2 SECURITY ASSOCIATION BLOCK..................................9
3.3 POLICY BLOCK...............................................10
3.4 NAME BLOCK.................................................11
4. APPLICATIONS................................................12
4.1 CONFIGURING AH.............................................12
4.2 CONFIGURING ESP............................................12
4.3 USE OF POLICY BLOCKS WITH KEY MANAGEMENT...................13
4.4 CONFIGURATION OF ISAKMP KEY MANAGEMENT.....................15
5. COMMAND REFERENCE...........................................15
BEGIN..........................................................15
DESTINATION....................................................16
DESTINATION-MASK...............................................16
END............................................................16
PARAMETER OR OPTPARAM..........................................16
allow-local-modification .....................................16
authentication-lifekbytes ....................................17
authentication-lifepackets ...................................17
authentication-lifetime ......................................17
Thayer,Doraswamy [Page 2]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
authority-info ...............................................17
certificate-info .............................................17
encryption-lifekbytes ........................................18
encryption-lifepackets .......................................18
encryption-lifetime ..........................................18
export .......................................................18
generated-by .................................................18
hmac-md5 .....................................................18
hmac-sha .....................................................19
ipsec-group ..................................................19
key-value ....................................................19
kms-authentication ...........................................19
kms-encryption ...............................................19
kms-group ....................................................19
kms-hash .....................................................20
merge ........................................................20
name .........................................................20
pfs ..........................................................20
policy-name ..................................................20
private-key-info .............................................20
sa-lifekbytes ................................................21
sa-lifepackets ...............................................21
sa-lifetime ..................................................21
spi ..........................................................21
tunnel .......................................................21
window-size ..................................................21
PEER...........................................................22
PRECEDENCE.....................................................22
SOURCE.........................................................22
SOURCE-MASK....................................................23
TRANSFORM......................................................23
6. SECURITY CONSIDERATIONS.....................................23
7. REFERENCES..................................................23
8. AUTHOR'S ADDRESSES..........................................24
APPENDIX.......................................................25
Thayer,Doraswamy [Page 3]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
A. EXAMPLE OF SECURITY ASSOCIATION BLOCK.......................25
B. EXAMPLE OF POLICY BLOCK.....................................26
C. REVISION HISTORY............................................28
Thayer,Doraswamy [Page 4]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
1. Introduction
There is a need to configure hosts running IP Security through an
out-of-band mechanism. This is needed when manually keyed
Security Associations are used, when Pre-defined Shared Secrets
are used for ISAKMP Key Management [ISAKMP-OAKLEY], and where
general security policy information must be distributed from a
central site such as a site-wide IPsec-aware Firewall.
This document defines a file format that can be used to specify
these IPsec policy and configuration information. It is intended
for use in environments where the IPsec policy information must
be shared among several systems, such as a firewall and several
remote nodes. The intent is that the files would be used to
define the policy and/or specific security association
configuration, with the files being distributed to the various
hosts to configure them. Since the file may contain shared-
secret values an encrypted format is specified.
1.1 Terms
Block - a collection of lines that describes one set of
parameters. A block is delimited by BEGIN and END commands.
Line - a single sequence of text terminated by some line
terminator. A line may be up to 128 characters in length. A
line is terminated by CR/LF/FF/Null in the ASCII case.
Policy - a description of the all the non-specific
characteristics of the security associations used between a pair
of nodes. This includes things like what transform to use, but
does NOT include specific values such as keying material or SPI
values.
White Space - space between tokens. White space must be SPACE or
TAB characters.
1.2 Requirements Terminology
In this document, the words that are used to define the
significance of each particular requirement are usually
capitalized. These words are:
Thayer,Doraswamy [Page 5]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
. MUST - This word or the adjective "REQUIRED" means that the
item is an absolute requirement of the specification.
. SHOULD - This word or the adjective "RECOMMENDED" means that
there might exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and the case carefully weighed before taking a
different course.
. MAY - This word or the adjective "OPTIONAL" means that this
item is truly optional. One vendor might choose to include
the item because a particular marketplace requires it or
because it enhances the product, for example; another vendor
may omit the same item.
2. General Formatting
The format of this file is designed to provide these features:
- secure storage with a flexible set of cryptographic
mechanisms
- able to be migrated forward to ISO 10646 (multi-byte) text
The file contains this:
. an identifier line
. one or more blocks
The identifier line is always clear text (including a line
terminator of NEWLINE). The blocks that follow it are usually
encrypted but may not be.
2.1 Format of Identifier Line
The first 42 characters of the file are this string, always
stored in clear text.
#RRRR-OOOO-SSSSSSSSSSSSSSSS-SECURITY FILE-
RRRR is the revision number. The revision is currently 0100.
OOOO is an option bit mask, defined below. This is a hex
representation of this bitmask.
Thayer,Doraswamy [Page 6]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
SSS...SSS is 16 characters of salt.
The option bits are:
0x00000001 - ARCFOUR [ARCFOUR] 40 encryption
0x00000002 - ARCFOUR 128 encryption
0x00000004 - DES encryption
0x00000008 - 3DES encryption
0x80000000 - text is US-ASCII
0x40000000 - text is ISO 10646
(Note the IETF-compliant default is DES [DES].)
The encrypted data contains text, currently in US-ASCII but can
be ISO 10646 in the future. The encrypted text can be checked
for integrity by confirming there is at least one parsable block.
2.1 Configuration Line Formatting Rules
The text consists of lines of arbitrary length. Lines are
terminated by one of these line terminators:
- Hex 0x00 (Null)
- Hex 0x0d (CR)
- Hex 0x0a (LF)
- Hex 0x0c (FF)
There may be blank lines, these are ignored.
There may be comment lines. These start with the character '#'
as the first character.
The text consists of lines of 'commands' grouped into 'blocks'.
Commands consist of combinations of keywords and values. These
are separated by 'white space', which may be any number of spaces
or tabs. There may be any number of blocks in a single file.
2.2 Keywords
The keywords listed here, in US English, MUST be supported. At a
later time other alternative keyword text, possibly in a
different language, may be substituted.
Thayer,Doraswamy [Page 7]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
Keywords are shown in UPPER CASE in this document for clarity.
In the actual file the keywords are case-insensitive.
If a command contains a keyword that is not recognized by an
implementation, the command SHOULD be ignored.
3. Block Contents
Parameters are organized in one of four possible blocks,
Configuration, Security Association, Policy, or Name. Any number
of these blocks may appear in a single file. Each block is
delimited by a BEGIN...END pair.
Blocks may appear in any order. There MUST be exactly one
Configuration block and it SHOULD appear first in the file.
3.1 Configuration Block
The configuration block covers information not specific to a
single Security Association or Policy Statement.
It contains a begin command, one or more parameter commands, and
an end command. If there are no parameters it is not required.
A block with no parameter commands shall be silently ignored.
Example:
BEGIN CONFIGURATION <name>
PARAMETER <param-name> <value>
END
There are one or more PARAMETER statements. Parameters are
represented in a name-value format, where <param-name> is the
name of the parameter, and <value> is a value, expressed as a
decimal number.
A configuration block SHOULD have these parameters defined:
. ALLOW-LOCAL-MODIFICATION
. EXPORT
. GENERATED-BY
. MERGE
Thayer,Doraswamy [Page 8]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
3.2 Security Association Block
The security association block is used to fully specify a
security association for a host. If you use manual keying you
use this. For example, if you use a firewall to dictate the
configuration of a manually-keyed Security Assocation for client
PC's, you would also use this. It must contain:
. begin command
. source address
. destination address
. precedence
. transform
. end command
It also may contain:
. source mask
. destination mask
. peer address
. certain parameters (see command reference for details)
It contains a begin command, commands specifying the security
association, one or more parameter commands, and an end command.
Note this block WILL contain pre-shared secrets and therefore
MUST be encrypted. If you wish to specify a manally keyed
security association then the file MUST contain at least one of
these blocks.
Example:
BEGIN SECURITY-ASSOCIATION sa-block-1
SOURCE IPV4 10.1.0.1
SOURCE-MASK IPV4 255.255.255.255
DESTINATION IPV4 10.2.0.1
DESTINATION-MASK IPv4 255.255.255.255
PEER IPv4 10.2.0.254
TRANSFORM ESP-DES-CBC
PRECEDENCE 1
PARAMETER SPI 00000101
PARAMETER KEY-VALUE 0b0b0b0b0b0b0b0b
PARAMETER TUNNEL 1
END
Thayer,Doraswamy [Page 9]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
The source and destination address are required. There may be
masks specified for either source or destination or both. A peer
may be specified if appropriate.
The name specified in the BEGIN command ('sa-block-1' in the
example) is any text name (must not include separators.) The
name must be unique within this file. The name MUST be a maximum
of 40 characters.
The parameters are used to specify (possibly optional) values
used for this block.
If tunnel mode is used then there MUST be a peer address and
there SHOULD be a tunnel parameter. (The specification of a peer
address implies tunnel mode.)
3.3 Policy Block
The policy block is similar to the security association block,
except 'policy' is advisory in nature and does not specify
precise parameters. It is used for situations where key
management or other general rules apply to the use of IP
Security. There may be several policy blocks specifying
alternative choices for a given
source/destination/peer/precedence combination.
A policy block must contain:
. begin command
. source address
. destination address
. transform
. precedence
. end command
It may also contain:
. certain parameters (see command reference for details)
. peer address
. destination mask
. source mask
It contains a begin command, commands specifying the policy, one
or more parameter commands, and an end command. Note this block
will not contain keying material. If you wish to specify policy
Thayer,Doraswamy [Page 10]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
for use by a key management component then the file MUST contain
at least one of these blocks. The block will be used by the key
management system and therefore may apply to both incoming and
outgoing Security Associations.
Example:
BEGIN POLICY policy-block-1
SOURCE IPV4 10.1.0.1
DESTINATION IPV4 10.2.0.1
TRANSFORM AH-MD5
PRECEDENCE 1
END
The source and destination address are required. There may be
masks specified for either source or destination or both. A peer
may be specified if appropriate.
The name specified in the BEGIN command ('policy-block-1' in the
example) is any text name (must not include separators.) The name
may be a maximum of 40 characters.
The parameter name/value pairs are specific to the transform.
These keywords are defined, others are allowed:
TUNNEL
If tunnel mode is used then there MUST be a peer address and
there SHOULD be a tunnel parameter.
3.4 Name Block
The name block contains identity information and also identifies
what policy or security association blocks within a single file
that it is associated with. There may be multiple name blocks in
a single file.
It contains a name parameter, used to identify the user,
certificate information, and certificate authority information.
The 'name' parameter identifies the user. The 'policy-name'
parameter identifies a group of policy blocks in this file that
this name information applies to.
Thayer,Doraswamy [Page 11]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
The certificate-info parameter may occur more than once and
contains BER-encoded data. Multiple certificate-info parameters
are appended together before use. In this way a whole X.509
certificate could be specified, although it would probably be
more convenient to use it for LDAP [ldap] query information.
The authority-info parameter may occur more than once and
contains BER-encoded data. It is intended for use in specifying
the Distinguished Name (see [pkix]) of the Certificate Authority
used. Multiple authority-info parameters are appended together
before use. In this way a whole X.509 certificate could be
specified, although it would probably be more convenient to use
it for LDAP [ldap] query information.
Example:
begin name thing1-identity
parameter name system-operator
parameter policy-name thing1-policy-block
parameter certificate-info 3082175614568ad34
parameter authority-info 3082175614568ad35
end
4. Applications
4.1 Configuring AH
To configure either an S-A or a proposal block for AH, you
specify the transform and whatever parameters are required, such
as keying material. if tunneling is specified then a peer
address is included and possibly a tunnel parameter.
4.2 Configuring ESP
To configure either an S-A or a proposal block for ESP, you
specify the transform and whatever parameters are required, such
as keying material. If authentication is used there are
parameters to specify that and the keying material is larger. It
is legitimate to have two blocks, one S-A and one Proposal,
referring to the same pair of nodes. The manner in which this is
handled is assumed to be a local implementation issue.
Thayer,Doraswamy [Page 12]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
4.3 Use of Policy Blocks with Key Management
If a proposal is being built up then there will be one or more
policy blocks each of which contains the same source,
destination, and precedence but different transforms and
parameters. These would be used to specify the various
transforms to use, such as "AH and ESP", and to specify
encryption schemes to use, such as "ESP with Triple DES or ESP
with DES."
If there are two or more alternatives being described for a given
source/destination combination, they are considered to be in
priority order. If more than one layer of IPsec transform is to
be applied then the precedence value indicates how to apply the
transforms.
Two policy blocks apply to the same source/destination
combination if they:
. same name
. same source/mask
. same destination/mask
. same peer (or both have no peer address)
If all these fields match but the precedence values are different
then the two blocks are parts of the same proposal combination.
If all these fields match but the precedence values are the same
then the two blocks are parts of two different proposals.
Here is an example. Suppose two nodes, 10.0.0.1 and 10.0.0.2,
will use IPsec. We are configuring this from the point of view
of 10.0.0.1. We will support one of:
1.MD5 AH plus Triple-DES ESP
2.SHA-1 AH plus Triple-DES ESP
3.Triple-DES ESP with SHA-1 authentication
4.Triple-DES ESP with MD5 authentication
We would prefer to do choice (3), Triple-DES ESP with SHA-1
authentication, as our first choice. Here are the policy blocks
that must be in the file, in order:
# note our preferred choice is first
Thayer,Doraswamy [Page 13]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
begin policy 4.1-sample
source ipv4 10.0.0.1
destination ipv4 10.0.0.2
precedence 1
transform esp-3des
parameter hmac-sha 1
end
# note all the blocks have the same name
begin policy 4.1-sample
source ipv4 10.0.0.1
destination ipv4 10.0.0.2
precedence 1
transform esp-3des
parameter hmac-md5 1
end
# note this block has no authentication parameter
# this will be used by both of the following AH
# policy blocks
begin policy 4.1-sample
source ipv4 10.0.0.1
destination ipv4 10.0.0.2
precedence 1
transform esp-3des
end
# note this block has a precedence of 2 so you know it
# goes with something else (i.e. the previous block)
begin policy 4.1-sample
source ipv4 10.0.0.1
destination 10.0.0.2
precedence 2
transform ah-sha1
end
# note this is the second ah choice and it too goes with
# the esp block above
begin policy 4.1-sample
source ipv4 10.0.0.1
destination 10.0.0.2
precedence 2
transform ah-md5
end
Thayer,Doraswamy [Page 14]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
4.4 Configuration of ISAKMP Key Management
ISAKMP security associations are configured using a variant of
the policy block, which can include a KEY-VALUE parameter for
pre-shared secrets. See the additional non-DOI names in the
TRANSFORM description also.
For the ISAKMP/Oakley Security Association negotiation, you would
have a Transform of Oakley, an encryption algorithm parameter, a
hash algorithm parameter, an authentication parameter, and a pre-
shared secret. Since there are multiple possibilities for
encryption algorithm, hash algorithm, and authentication scheme,
there would be multiple policy blocks.
Example:
begin policy ed-kms-sample-1
# example ISAKMP/Oakley S-A Proposal (one of a set)
transform key-oakley
parameter kms-encryption key-encrypt-des
parameter kms-hash key-hash-md5
parameter kms-authentication key-auth-pre-shared
parameter key-value 313233343536373839
parameter pfs 1
end
5. Command Reference
Each line of a block contains one command. This section contains
reference information for each command. See the descriptions of
the individual blocks for an explanation of which commands apply
to which blocks.
BEGIN
The BEGIN command marks the beginning of a block. There are
three possible formats:
BEGIN CONFIGURATION <name>
BEGIN SECURITY-ASSOCIATION <name>
BEGIN POLICY <name>
The name is case sensitive. This is the only value that is case
sensitive. All blocks must have a name.
Thayer,Doraswamy [Page 15]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
DESTINATION
The DESTINATION command contains an Ipv4 or Ipv6 destination
address. The format is:
DESTINATION <addr-type> <addr-value>
where addr-type is ipv4 or ipv6. The address for Ipv4 is a 4 part
dotted tuple in decimal (i.e. "10.9.8.7".)
DESTINATION-MASK
The DESTINATION-MASK command contains an Ipv4 or Ipv6 network
mask. The format is:
DESTINATION-MASK <addr-type> <addr-mask-value>
where addr-type is ipv4 or ipv6 and addr-mask-value is a mask, in
n.n.n.n (i.e. 255.255.255.0 like CIDR [CIDR]) format for ipv4.
END
The END command marks the end of a block.
PARAMETER or OPTPARAM
The PARAMETER command contains a configuration value. The format
is:
PARAMETER <param-name> <value>
OPTPARAM is the same as PARAMETER except it indicates this
parameter may be treated as optional. This means an
implementation MAY ignore an OPTPARAM command if it wishes.
Private parameters are allowed, as well as the following general
parameters:
allow-local-modification
ALLOW-LOCAL-MODIFICATION <1 or 0>
This parameter indicates whether the file may be edited within
the local host. A value of 1 means allow editing, 0 means do not
Thayer,Doraswamy [Page 16]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
allow editing. The default value should be 1. This is valid in
config blocks only.
authentication-lifekbytes
AUTHENTICATION-LIFEKBYTES <value1>
Lifetime of authentication key, in kilobytes.
authentication-lifepackets
AUTHENTICATION-LIFEPACKETS <value1>
Lifetime of authentication key, in packets.
authentication-lifetime
AUTHENTICATION-LIFETIME <value1>
Lifetime of authentication key, in seconds.
authority-info
AUTHORITY-INFO <ber-fragment>
This parameter contains part or all of a BER-encoded certificate
authority root certificate or certificate reference. If more
than one AUTHORITY-INFO parameter appears within a single name
block then the values are to be appended together before use.
certificate-info
CERTIFICATE-INFO <ber-fragment>
This parameter contains part or all of a BER-encoded certificate
or certificate reference. If more than one CERTIFICATE-INFO
parameter appears within a single name block then the values are
to be appended together before use.
Thayer,Doraswamy [Page 17]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
encryption-lifekbytes
ENCRYPTION-LIFEKBYTES <value1>
Lifetime of encryption key, in kilobytes.
encryption-lifepackets
ENCRYPTION-LIFEPACKETS <value1>
Lifetime of encryption key, in packets.
encryption-lifetime
ENCRYPTION-LIFETIME <value1>
Lifetime of encryption key, in seconds.
export
EXPORT <1 or 0>
This parameter indicates whether this file is intended to be safe
for export use relative to the country in which the file was
generated. A value of 1 means exportable, 0 means do not export.
The default value should be 1.
generated-by
GENERATED-BY <component>
This parameter indicates the vendor and/or component that
generated the file. This is a character string. Note that one
could use the string representation of an SNMP Enterprise Object
Identifier here, e.g. "enterprise.252.3.1.1".
hmac-md5
HMAC-MD5 1
This parameter is used in an ESP policy or security-association
block to indicate ESP authentication with HMAC-MD5. The value
(1) can be anything and is set to 1 by convention.
Thayer,Doraswamy [Page 18]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
hmac-sha
HMAC-SHA 1
This parameter is used in an ESP policy or security-association
block to indicate ESP authentication with HMAC-SHA-1. The value
(1) can be anything and is set to 1 by convention.
ipsec-group
ipsec-group 1
This parameter is used in a proposal to indicate what Group is to
be used when negotiating an IPsec Security Association.
key-value
KEY-VALUE <key in hex> (or)
KEY-VALUE "<value as text>"
Represents the key value for this block, in hex, or as a string.
kms-authentication
KMS-AUTHENTICATION <auth-scheme-name>
Authentication scheme for ISAKMP/OAKLEY. Possible values are 1
for pre-shared secret, 2 for DSS, or 3 for RSA.
kms-encryption
KMS-ENCRYPTION <encryption-number>
Encryption scheme for ISAKMP/OAKLEY. Possible values are from
the list of "Class Values" in Appendix A of [ISAKMP-OAKLEY].
kms-group
KMS-GROUP <1>
specifies Oakley Default Group. Must be a 1.
Thayer,Doraswamy [Page 19]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
kms-hash
KMS-HASH <hash-number>
Hashing scheme for ISAKMP/OAKLEY. Possible values are from the
list of "Hash Algorithms" in Appendix A of [ISAKMP-OAKLEY].
merge
MERGE <1 or 0>
This parameter indicates whether this file may be merged into
existing local security information store if that is relevant. A
value of 0 means overwrite the current value. A value of 1
means do not overwrite if there is a conflict. If there is no
merge parameter then "merge 0' is assumed.
name
NAME <username>
This parameter specifies a username for use in name blocks.
pfs
PFS <1 or 0>
If 1, ISAKMP/OAKLEY will use Perfect Forward Secrecy.
policy-name
POLICY-NAME <blockname>
This parameter specifies what policy block set is to use a given
name block. This parameter MUST only appear in name blocks.
private-key-info
PRIVATE-KEY-INFO <fragment>
This parameter contains part or all of a private key associated
with a certificate. If more than one PRIVATE-KEY-INFO parameter
appears within a single name block then the values are to be
Thayer,Doraswamy [Page 20]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
appended together before use. NOTE THE FORMAT OF THE FRAGMENT IS
T.B.D. It might be BER from some PKCS standard and it might
not...
sa-lifekbytes
SA-LIFEKBYTES <value1>
Lifetime of security association key, in kilobytes.
sa-lifepackets
SA-LIFEPACKETS <value1>
Lifetime of security association, in packets.
sa-lifetime
SA-LIFETIME <value1>
Lifetime of security association, in seconds.
spi
SPI <value in hex>
this is the SPI number for security association blocks.
tunnel
TUNNEL 1
this parameter indicates that tunnel mode is to be used. Note
the actual value can be anything, by convention a 1 is specified.
window-size
WINDOW-SIZE <value>
This is the window size for transforms that use replay checking
on input of negotiated security associations. This may appear
only in a policy block.
Thayer,Doraswamy [Page 21]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
PEER
The PEER command specifies the other end of an Ipv4 or Ipv6
tunnel. The format is:
PEER <addr-type> <addr-value>
where addr-type is ipv4 or ipv6. If there is a PEER command in a
block then that block specifies tunnel mode.
PRECEDENCE
The PRECEDENCE command specifies the order in which security
protocol headers are placed in an IP packet. For example, a
regular Ipv4 packet looks like this:
IP Header -- Payload
Then, adding one AH header, you have
IP Header -- AH Header -- Payload
If there are multiple headers, the order must be specified to
avoid confusion. The 'precedence' does this. The INNER-MOST
security header, the one nearest the payload, is numbered ONE.
For example, a packet with AH and two ESP headers, like this:
IP -- AH[x] -- ESP[y] -- ESP[z] -- Payload
has precedence 1 for ESP[z], precedence 2 for ESP[y], and
precedence 3 for AH[x].
SOURCE
The SOURCE command contains an Ipv4 or Ipv6 source address. The
format is:
SOURCE <addr-type> <addr-value>
where addr-type is ipv4 or ipv6. The address for Ipv4 is a 4
part dotted tuple in decimal (i.e. "10.9.8.7".)
Thayer,Doraswamy [Page 22]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
SOURCE-MASK
The SOURCE-MASK command contains an Ipv4 or Ipv6 network mask.
The format is:
SOURCE-MASK <addr-type> <addr-mask-value>
where addr-type is ipv4 or ipv6 and addr-mask-value is a mask, in
n.n.n.n (i.e. 255.255.255.0 like CIDR [CIDR]) format for ipv4.
TRANSFORM
The TRANSFORM command specifies what cryptographic transform is
to be used. The <doi-name> field of the TRANSFORM entry is a name
from [DOI], currently these include:
AH-1828
AH-HMAC-MD5
AH-HMAC-SHA
ESP-1829
ESP-1829
ESP-DES-CBC
DENY-ALL
ALLOW-CLEAR
KEY-OAKLEY
In addition to the DOI transform names there are two special
values, DENY-ALL and ALLOW-CLEAR. DENY-ALL is used for
configuring a policy of blocking access to certain addresses.
ALLOW-CLEAR is used for configuring a policy of allowing clear
(un-encrypted and un-authenticated) access.
6. Security Considerations
This file format is used to store security information (e.g.
keys) used for IP Security between hosts. It therefore must be
protected appropriately. For this reason the file is always
stored in an encrypted manner using one of the defined encryption
schemes.
7. References
[ARCFOUR] to-be-resubmitted ARCFOUR (RC-4) draft
Thayer,Doraswamy [Page 23]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
[CIDR] Classless Inter-Domain Routing (CIDR): an Address
Assignment and Aggregation Strategy, RFC 1519.
[DES] US National Bureau of Standards, "Data Encryption
Standard", Federal Information Processing Standard (FIPS)
Publication 46, January, 1977.
[DOI] D. Piper, "The Internet IP Security Domain of
Interpretation for ISAKMP", draft-ietf-ipsec-doi-01.txt.
[ISAKMP-OAKLEY] D.Harkins, D.Carrel, "The resolution of ISAKMP
with Oakley", draft-ietf-ipsec-isakmp-oakley-03.txt.
[LDAP]
[PKIX] part 1.
[RFC-1825] R. Atkinson, "Security Architecture for the Internet
Protocol", 08/09/1995. (Pages=22) (Format=.txt)
8. Author's Addresses
Rodney Thayer
Sable Technology Corporation
246 Walnut Street
Newton Massachusetts 02160
rodney@sabletech.com
+1 617 332 7292
Fax +1 617 332 7970
Naganand Doraswamy
FTP Software
2 High Street
North Andover, Massachusetts
naganand@ftp.com
+1 508 685 4000
Thayer,Doraswamy [Page 24]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
Appendix
A. Example of Security Association Block
Here is an example of an Import/Export File.
# Sample IPSEC Import/Export File
BEGIN CONFIGURATION config1
PARAMETER ALLOW-LOCAL-MODIFICATION 1
PARAMETER generated-by enterprise.252.2.1
END
BEGIN SECURITY-ASSOCIATION sample-ah
SOURCE IPV4 10.0.0.1
DESTINATION IPV4 10.2.0.0
DESTINATION-MASK IPV4 255.255.255.0
PEER IPV4 10.0.0.2
TRANSFORM AH-1828
PRECEDENCE 2
PARAMETER SPI 11110001
PARAMETER KEY-VALUE 12345678123456781234567812345678
END
BEGIN SECURITY-ASSOCIATION sample-esp
SOURCE IPV4 10.0.0.1
DESTINATION IPV4 10.2.0.0
DESTINATION-MASK IPV4 255.255.255.0
PEER IPV4 10.0.0.2
TRANSFORM ESP-1829
PRECEDENCE 1
PARAMETER SPI 11110002
PARAMETER KEY-VALUE 9999888877776666
END
Thayer,Doraswamy [Page 25]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
B. Example of Policy Block
# this says it's export-controlled, can be locally modified,
# and sable.2.1 generated it.
#
BEGIN CONFIGURATION
PARAMETER EXPORT 0
PARAMETER ALLOW-LOCAL-MODIFICATION 1
PARAMETER generated-by enterprise.252.2.1
END
#
# this says 10.1.0.1 to 10.1.0.2 uses either md5 or sha1 for AH
# note spi and key are set by the key management component
#
BEGIN POLICY thing1-thing2-ah
SOURCE IPV4 10.1.0.1
DESTINATION IPV4 10.1.0.2
transform ah-1828
precedence 1
END
begin policy thing1-thing2-ah
source ipv4 10.1.0.1
destination ipv4 10.1.0.2
transform ah-sha1
precedence 1
end
#
# this says 10.1.0.2 to 10.1.0.1 uses either md5 or sha1 for AH
# note spi and key are set by the key management component
#
BEGIN POLICY thing2-thing1-ah
SOURCE IPV4 10.1.0.2
DESTINATION IPV4 10.1.0.1
transform ah-1828
precedence 1
END
begin policy thing2-thing1-ah
source ipv4 10.1.0.2
destination ipv4 10.1.0.1
transform ah-sha1
precedence 1
end
Thayer,Doraswamy [Page 26]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
#
# this says 10.1.0.1 to 10.1.0.2 uses des for ESP
#
begin policy thing1-thing2-esp
source ipv4 10.1.0.1
destination ipv4 10.1.0.2
transform esp-1829
precedence 1
end
#
# this says 10.1.0.2 to 10.1.0.1 uses des for ESP
#
begin policy thing2-thing1-esp
source ipv4 10.1.0.2
destination ipv4 10.1.0.1
transform esp-1829-transport
precedence 1
end
# this entry says client 10.1.0.3 uses a tunnel to 10.3.0.99 for
# subnet 10.2.0.0/255.255.0.0
begin policy thing3
source ipv4 10.1.0.3
destination ipv4 10.2.0.0
destination-mask ipv4 255.255.0.0
peer ipv4 10.3.0.99
precedence 1
transform esp-des-cbc
parameter window-size 40
parameter hmac-sha 1
end
Thayer,Doraswamy [Page 27]
INTERNET-DRAFT IPSEC Import/Export Format April 1997
C. Revision History
This is revision 01 of this document.
Changes from revision 00:
1.changed identification field at front of file into printable
text.
2.added authentication-lifepackets, encryption-lifepackets, sa-
lifepackets
3.general text cleanup
4.more information in the parameter descriptions
5.added name block
6.added ipsec-group, changed group to kms-group, removed
'priority', 'direction'
THIS DOCUMENT EXPIRES DECEMBER 1997.
Thayer,Doraswamy [Page 28]