| ISAKMPD.POLICY(5) | File Formats Manual | ISAKMPD.POLICY(5) |
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:
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" ||
"passphrase-sha1-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 "passphrase-md5-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 pseudo-credentials. 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:
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.
isakmpd policy configuration
file.isakmpd policy configuration file. Authorizer: "POLICY"
Comment: This bare-bones assertion accepts everything
Authorizer: "POLICY"
Licensees: "passphrase-md5-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: "passphrase-md5-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" ||
"passphrase-sha1-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="
A more sane way of expressing IPv6 address ranges is needed.
| June 15, 2002 | Debian |