|
|
ISAKMPD.POLICY(5)
Contents
|
isakmpd.policy - policy configuration file for isakmpd
isakmpd.policy is the policy configuration file for the
isakmpd daemon
managing security association and key management for the
ipsec(4) layer
of the kernel's networking stack.
The isakmpd(8) daemon (also known as IKE, for Internet Key
Exchange) is
used when two systems need to automatically set up a pair of
Security Associations
(SAs) for securely communicating using IPsec.
IKE operates in
two stages:
In the first stage (Main or Identity Protection Mode), the
two IKE daemons
establish a secure link between themselves, fully authenticating
each other and establishing key material for encrypting/authenticating
future communications between them. This step is typically
only performed
once for every pair of IKE daemons.
In the second stage (also called Quick Mode), the two IKE
daemons create
the pair of SAs for the parties that wish to communicate using IPsec.
These parties may be the hosts the IKE daemons run on, a
host and a network
behind a firewall, or two networks behind their respective firewalls.
At this stage, the exact parameters of the SAs
(e.g., algorithms
to use, encapsulation mode, lifetime) and the identities of
the communicating
parties (hosts, networks, etc.) are specified. The
reason for the
existence of Quick Mode is to allow for fast SA setup, once
the more
heavy-weight Main Mode has been completed. Generally, Quick
Mode uses
the key material derived from Main Mode to provide keys to
the IPsec
transforms to be used. Alternatively, a new Diffie-Hellman
computation
may be performed (significantly slowing down the exchange,
but at the
same time providing Perfect Forward Secrecy (PFS)).
Briefly, this means
that even should an attacker manage to break long-term keys
used in other
sessions (or, specifically, if an attacker breaks the
Diffie-Hellman exchange
performed during Main Mode), they will not be able to
decrypt this
traffic. Normally, no PFS is provided (the key material
used by the
IPsec SAs established as a result of this exchange will be
derived from
the key material of the Main Mode exchange), allowing for a
faster Quick
Mode exchange (no public key computations).
IKE proposals are "suggestions" by the initiator of an exchange to the
responder as to what protocols and attributes should be used
on a class
of packets. For example, a given exchange may ask for ESP
with 3DES and
MD5 and AH with SHA1 (applied successively on the same packet), or just
ESP with Blowfish and RIPEMD-160. The responder examines
the proposals
and determines which of them are acceptable, according to
policy and any
credentials.
The following paragraphs assume some knowledge of the contents of the
keynote(4) and keynote(5) man pages.
In the KeyNote policy model for IPsec, no distinction is
currently made
based on the ordering of AH and ESP in the packet. Should
this change in
the future, an appropriate attribute (see below) will be
added.
The goal of security policy for IKE is thus to determine,
based on local
policy (provided in the isakmpd.policy file), credentials
provided during
the IKE exchanges (or obtained through other means), the SA
attributes
proposed during the exchange, and perhaps other (side-channel) information,
whether a pair of SAs should be installed in the system (in fact,
whether both the IPsec SAs and the flows should be installed). For each
proposal suggested by or to the remote IKE daemon, the
KeyNote system is
consulted as to whether the proposal is acceptable based on
local policy
(contained in isakmpd.policy, in the form of policy assertions) and remote
credentials (e.g., KeyNote credentials or X509 certificates provided
by the remote IKE daemon).
isakmpd.policy is simply a flat ascii(7) file containing
KeyNote policy
assertions, separated by blank lines (note that KeyNote assertions may
not contain blank lines). isakmpd.policy is read when
isakmpd(8) is
first started, and every time it receives a SIGHUP signal.
The new policies
read will be used for all new Phase 2 (IPsec) SAs established from
that point on (even if the associated Phase 1 SA was already
established
when the new policies were loaded). The policy change will
not affect
already established Phase 2 SAs.
For more details on KeyNote assertion format, please see
keynote(5).
Briefly, KeyNote policy assertions used in IKE have the following characteristics:
+o The Authorizer field is typically "POLICY" (but see the
examples below,
for use of policy delegation).
+o The Licensees field can be an expression of passphrases
used for authentication
of the Main Mode exchanges, and/or public
keys (typically,
X509 certificates), and/or X509 distinguished names.
+o The Conditions field contains an expression of attributes from the
IPsec policy action set (see below as well as the
keynote syntax man
page for more details).
+o The ordered return-values set for IPsec policy is
"false, true".
For an explanation of these fields and their semantics, see
keynote(5).
For example, the following policy assertion:
Authorizer: "POLICY"
Licensees: "passphrase:foobar" || "x509-base64:abcd=="
||
"passphrase-md5-hex:3858f62230ac3c915f300c664312c63f"
||
"passphrasesha1-hex:8843d7f92416211de9ebb963ff4ce28125932878"
Conditions: app_domain == "IPsec policy" && esp_present
== "yes"
&& esp_enc_alg != "null" -> "true";
says that any proposal from a remote host that authenticates
using the
passphrase "foobar" or the public key contained in the X509
certificate
encoded as "abcd==" will be accepted, as long as it contains
ESP with a
non-null algorithm (i.e., the packet will be encrypted).
The last two
authorizers are the MD5 and SHA1 hashes respectively of the
passphrase
"foobar". This form may be used instead of the
"passphrase:..." one to
protect the passphrase as included in the policy file (or as
distributed
in a signed credential).
The following policy assertion:
Authorizer: "POLICY"
Licensees: "DN:/CN=CA Certificate"
Conditions: app_domain == "IPsec policy" && esp_present
== "yes"
&& esp_enc_alg != "null" -> "true";
is similar to the previous one, but instead of including a
complete X509
credential in the Licensees field, only the X509 certificate's Subject
Canonical Name needs to be specified (note that the "DN:"
prefix is necessary).
KeyNote credentials have the same format as policy assertions, with one
difference: the Authorizer field always contains a public
key, and the
assertion is signed (and thus its integrity can be cryptographically verified).
Credentials are used to build chains of delegation
of authority.
They can be exchanged during an IKE exchange, or can be retrieved through
some out-of-band mechanism (no such mechanism is currently
supported in
this implementation however). See isakmpd.conf(5) on how to
specify what
credentials to send in an IKE exchange.
Passphrases that appear in the Licensees field are encoded
as the string
"passphrase:", followed by the passphrase itself (case-sensitive). Alternatively
(and preferably), they may be encoded using the
"passphrasemd5-hex:"
or "passphrase-sha1-hex:" prefixes, followed by
the md5(1) or
sha1(1) hash of the passphrase itself, encoded as a hexadecimal string
(using lower-case letters only).
When X509-based authentication is performed in Main Mode,
any X509 certificates
received from the remote IKE daemon are converted
to very simple
KeyNote credentials. The conversion is straightforward:
the issuer
of the X509 certificate becomes the Authorizer of the
KeyNote credential,
the subject becomes the only Licensees entry, while the Conditions field
simply asserts that the credential is only valid for "IPsec
policy" use
(see the app_domain action attribute below).
Similarly, any X509 CA certificates present in the directory
pointed to
by the appropriate isakmpd.conf(5) entry, are converted to
such pseudocredentials.
This allows one to write KeyNote policies that
delegate
specific authority to CAs (and the keys those CAs certify,
recursively).
For more details on KeyNote assertion format, see
keynote(5).
Information about the proposals, the identity of the remote
IKE daemon,
the packet classes to be protected, etc. are encoded in what
is called an
action set. The action set is composed of name-value attributes, similar
in some ways to shell environment variables. These values
are initialized
by isakmpd before each query to the KeyNote system, and
can be tested
against in the Conditions field of assertions. See
keynote(4) and
keynote(5) for more details on the format and semantics of
the Conditions
field.
Note that assertions and credentials can make references to
non-existent
attributes without catastrophic failures (access may be denied, depending
on the overall structure, but will not be accidentally
granted). One
reason for credentials referencing non-existent attributes
is that they
were defined within a specific implementation or network only.
In the following attribute set, IPv4 addresses are encoded
as ASCII
strings in the usual dotted-quad format. However, all quads
are three
digits long. For example, the IPv4 address 10.128.1.12
would be encoded
as 010.128.001.012. Similarly, IPv6 addresses are encoded
in the standard
x:x:x:x:x:x:x:x format, where the 'x's are the hexadecimal values of
the eight 16-bit pieces of the address. All 'x's are four
digits long.
For example, the address 1080:0:12:0:8:800:200C:417A would
be encoded as
1080:0000:0012:0000:0008:0800:200C:417A.
The following attributes are currently defined:
app_domain
Always set to IPsec policy.
doi Always set to ipsec.
initiator
Set to yes if the local daemon is initiating the
Phase 2 SA, no
otherwise.
phase_1 Set to aggressive if aggressive mode was used to
establish the
Phase 1 SA, or main if main mode was used instead.
pfs Set to yes if a Diffie-Hellman exchange will be
performed during
this Quick Mode, no otherwise.
ah_present, esp_present, comp_present
Set to yes if an AH, ESP, or compression proposal
was received
respectively, no otherwise.
ah_hash_alg
One of md5, sha, ripemd, sha2-256, sha2-385,
sha2-512, or des,
based on the hash algorithm specified in the AH
proposal. This
attribute describes the generic transform to be
used in the AH
authentication.
esp_enc_alg
One of des, des-iv64, 3des, rc4, idea, cast,
blowfish, 3idea,
des-iv32, rc4, null, or aes, based on the encryption algorithm
specified in the ESP proposal.
comp_alg
One of oui, deflate, lzs, or v42bis, based on the
compression
algorithm specified in the compression proposal.
ah_auth_alg
One of hmac-md5, hmac-sha, des-mac, kpdk,
hmac-sha2-256, hmac-
sha2-385, hmac-sha2-512, or hmac-ripemd. based on
the authentication
method specified in the AH proposal.
esp_auth_alg
One of hmac-md5, hmac-sha, des-mac, kpdk,
hmac-sha2-256, hmac-
sha2-385, hmac-sha2-512, or hmac-ripemd based on
the authentication
method specified in the ESP proposal.
ah_life_seconds, esp_life_seconds, comp_life_seconds
Set to the lifetime of the AH, ESP, and compression
proposal, in
seconds. If no lifetime was proposed for the corresponding protocol
(e.g., there was no proposal for AH), the
corresponding
attribute will be set to zero.
ah_life_kbytes, esp_life_kbytes, comp_life_kbytes
Set to the lifetime of the AH, ESP, and compression
proposal, in
kbytes of traffic. If no lifetime was proposed for
the corresponding
protocol (e.g., there was no proposal for
AH), the corresponding
attribute will be set to zero.
ah_encapsulation, esp_encapsulation, comp_encapsulation
Set to tunnel or transport, based on the AH, ESP,
and compression
proposal.
ah_ecn, esp_ecn, comp_ecn
Set to yes or no, based on whether ECN was requested for the
IPsec tunnel.
comp_dict_size
Specifies the log2 maximum size of the dictionary,
according to
the compression proposal.
comp_private_alg
Set to an integer specifying the private algorithm
in use, according
to the compression proposal.
ah_key_length, esp_key_length
The number of key bits to be used by the authentication and encryption
algorithms respectively (for variable keysize algorithms).
ah_key_rounds, esp_key length
The number of rounds of the authentication and encryption algorithms
respectively (for variable round algorithms).
ah_group_desc, esp_group_desc, comp_group_desc
The Diffie-Hellman group identifier from the AH,
ESP, and compression
proposal, used for PFS during Quick Mode
(see the pfs
attribute above). If more than one of these attributes are set
to a value other than zero, they should have the
same value (in
valid IKE proposals). Valid values are 1 (768-bit
MODP), 2
(1024-bit MODP), 3 (155-bit EC), 4 (185-bit EC),
and 5 (1536-bit
MODP).
phase1_group_desc
The Diffie-Hellman group identifier used in IKE
Phase 1. Takes
the same values as ah_group_desc.
remote_filter_type, local_filter_type, remote_id_type
Set to IPv4 address, IPv4 range, IPv4 subnet, IPv6
address, IPv6
range, IPv6 subnet, FQDN, User FQDN, ASN1 DN, ASN1
GN, or Key
ID, based on the Quick Mode Initiator ID, Quick
Mode Responder
ID, and Main Mode peer ID respectively.
remote_filter_addr_upper, local_filter_addr_upper, remote_id_addr_upper
When the corresponding filter_type is IPv4 address
or IPv6
address, these contain the respective address. For
IPv4 range
or IPv6 range, they contain the upper end of the
address range.
For IPv4 subnet or IPv6 subnet, they contain the
highest address
in the specified subnet.
remote_filter_addr_lower, local_filter_addr_lower, remote_id_addr_lower
When the corresponding filter_type is IPv4 address
or IPv6
address, these contain the respective address. For
IPv4 range
or IPv6 range, these contain the lower end of the
address range.
For IPv4 subnet or IPv6 subnet, these contain the
lowest address
in the specified subnet.
remote_filter, local_filter, remote_id
When the corresponding filter_type specifies an address range or
subnet, these are set to the upper and lower part
of the address
space separated by a dash ('-') character (if the
type specifies
a single address, they are set to that address).
For FQDN and User FQDN types, these are set to the
respective
string. For Key ID, these are set to the hexadecimal representation
of the associated byte string (lower-case
letters used)
if the Key ID payload contains non-printable characters. Otherwise,
they are set to the respective string.
For ASN1 DN, these are set to the text encoding of
the Distinguished
Name in the payload sent or received. The
format is the
same as that used in the Licensees field.
remote_filter_port, local_filter_port, remote_id_port
Set to the transport protocol port.
remote_filter_proto, local_filter_proto, remote_id_proto
Set to etherip, tcp, udp, or the transport protocol
number, depending
on the transport protocol set in the IDci,
IDcr, and
Main Mode peer ID respectively.
remote_negotiation_address
Set to the IPv4 or IPv6 address of the remote IKE
daemon.
local_negotiation_address
Set to the IPv4 or IPv6 address of the local interface used by
the local IKE daemon for this exchange.
GMTTimeOfDay
Set to the UTC date/time, in YYYYMMDDHHmmSS format.
LocalTimeOfDay
Set to the local date/time, in YYYYMMDDHHmmSS format.
/etc/isakmpd/isakmpd.policy The default isakmpd policy configuration
file.
/usr/share/ipsec/isakmpd/policy
A sample isakmpd policy configuration file.
Authorizer: "POLICY"
Comment: This bare-bones assertion accepts everything
Authorizer: "POLICY"
Licensees: "passphrasemd5-hex:10838982612aff543e2e62a67c786550"
Comment: This policy accepts anyone using shared-secret
authentication using the password mekmitasisgoat,
and does ESP with some form of encryption (not
null).
Conditions: app_domain == "IPsec policy" &&
esp_present == "yes" &&
esp_enc_alg != "null" -> "true";
Authorizer: "POLICY"
Licensees: "subpolicy1" || "subpolicy2"
Comment: Delegate to two other sub-policies, so we
can manage our policy better. Since these subpolicies
are not "owned" by a key (and are thus unsigned), they
have to be in isakmpd.policy.
Conditions: app_domain == "IPsec policy";
KeyNote-Version: 2
Licensees: "passphrasemd5-hex:9c42a1346e333a770904b2a2b37fa7d3"
Conditions: esp_present == "yes" -> "true";
Authorizer: "subpolicy1"
Conditions: ah_present == "yes" ->
{
ah_auth_alg == "md5" -> "true";
ah_auth_alg == "sha" &&
esp_present == "no" -> "true";
};
Licensees: "passphrase:otherpassword" ||
"passphrasesha1-hex:f5ed6e4abd30c36a89409b5da7ecb542c9fbf00f"
Authorizer: "subpolicy2"
keynote-version: 2
comment: this is an example of a policy delegating to a
CN.
authorizer: "POLICY"
licensees: "DN:/CN=CA Certificate/emailAddress=ca@foo.bar.com"
keynote-version: 2
comment: This is an example of a policy delegating to a
key.
authorizer: "POLICY"
licensees: "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc
m91cC5jby51azAeFw05OTEwMTEyMjQ5MzhaFw05OTExMTAyMjQ5
MzhaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8
GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG
dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
QCxyAte2HEVouXg1Yu+vDihbnjDRn+6k00Rv6cZqbwA3BQ30mC/
3TFJ09VGXCaM0UKfpnxIpkBYLmOA3FWkKI0RvPU7E1AhKkhC1Ds
PSBFjYHrB15T5lYzgfwKJCIxTDzZDx2iobUgPa0FRNGVUjpQ4/k
MJ2BF4Wh7zY3X08rMzsQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA
DWJ5pbTcE7iKHWLQTMYiz8i9jGi5+Eo1yr1Bab90tgaGQV0zrRH
jDHgAAy1h8WSXuyQrXfgbx2rnWFPhx9CfmuAXn7sZmQE3mnUqeP
ZL2dW87jdBGqtoUdNcoz5zKBkC943yasNui/O01MiqgadTThTJH
d1Pn17LbJC1ZVRNjR5"
conditions: app_domain == "IPsec policy" && doi ==
"ipsec" &&
pfs == "yes" && esp_present == "yes" && ah_present == "no" &&
(esp_enc_alg == "3des" || esp_enc_alg == "aes")
-> "true";
keynote-version: 2
comment: This is an example of a credential, the signature does
not really verify (although the keys are real).
licensees: "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc
m91cC5jby51azAeFw05OTEwMTEyMzA2MjJaFw05OTExMTAyMzA2
MjJaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8
GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG
dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
QDaCs+JAB6YRKAVkoi1NkOpE1V3syApjBj0Ahjq5HqYAACo1JhM
+QsPwuSWCNhBT51HX6G6UzfY3mOUz/vou6MJ/wor8EdeTX4nucx
NSz/r6XI262aXezAp+GdBviuJZx3Q67ON/IWYrB4QtvihI4bMn5
E55nF6TKtUMJTdATvs/wIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA
MaQOSkaiR8id0h6Zo0VSB4HpBnjpWqz1jNG8N4RPN0W8muRA2b9
85GNP1bkC3fK1ZPpFTB0A76lLn11CfhAf/gV1iz3ELlUHo5J8nx
Pu6XfsGJm3HsXJOuvOog8Aean4ODo4KInuAsnbLzpGl0d+Jqa5u
TZUxsyg4QOBwYEU92H"
authorizer: "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc
m91cC5jby51azAeFw05OTEwMTEyMjQ5MzhaFw05OTExMTAyMjQ5
MzhaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8
GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG
dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
QCxyAte2HEVouXg1Yu+vDihbnjDRn+6k00Rv6cZqbwA3BQ30mC/
3TFJ09VGXCaM0UKfpnxIpkBYLmOA3FWkKI0RvPU7E1AhKkhC1Ds
PSBFjYHrB15T5lYzgfwKJCIxTDzZDx2iobUgPa0FRNGVUjpQ4/k
MJ2BF4Wh7zY3X08rMzsQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA
DWJ5pbTcE7iKHWLQTMYiz8i9jGi5+Eo1yr1Bab90tgaGQV0zrRH
jDHgAAy1h8WSXuyQrXfgbx2rnWFPhx9CfmuAXn7sZmQE3mnUqeP
ZL2dW87jdBGqtoUdNcoz5zKBkC943yasNui/O01MiqgadTThTJH
d1Pn17LbJC1ZVRNjR5"
conditions: app_domain == "IPsec policy" && doi == "ipsec"
&&
pfs == "yes" && esp_present == "yes" && ah_present == "no" &&
(esp_enc_alg == "3des" || esp_enc_alg == "aes")
-> "true";
Signature: "sig-x509-sha1-base64:ql+vrUxv14DcBOQHR2jsbXayq6T
mmtMiUB745a8rjwSrQwh+KIVDlUrghPnqhSIkWSDi9oWWMbfg
mkdudZ0wjgeTLMI2NI4GibMMsToakOKMex/0q4cpdpln3DKcQ
IcjzRv4khDws69FT3QfELjcpShvbLrXmh1Z00OFmxjyqDw="
ipsec(4), keynote(4), keynote(5), isakmpd(8)
A more sane way of expressing IPv6 address ranges is needed.
OpenBSD 3.6 June 15, 2002
[ Back ] |
