1.\" $OpenBSD: isakmpd.policy.5,v 1.51 2022/02/06 00:29:02 jsg Exp $ 2.\" $EOM: isakmpd.policy.5,v 1.24 2000/11/23 12:55:25 niklas Exp $ 3.\" 4.\" Copyright (c) 1999-2001, Angelos D. Keromytis. All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 15.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR 16.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 17.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 18.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, 19.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 20.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 21.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 22.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 23.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 24.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 25.\" 26.\" 27.\" Manual page, using -mandoc macros 28.\" 29.Dd $Mdocdate: February 6 2022 $ 30.Dt ISAKMPD.POLICY 5 31.Os 32.Sh NAME 33.Nm isakmpd.policy 34.Nd policy configuration file for isakmpd 35.Sh DESCRIPTION 36.Nm 37is the policy configuration file for the 38.Xr isakmpd 8 39daemon, managing security association and key management for the 40.Xr ipsec 4 41layer of the kernel's networking stack. 42The 43.Xr isakmpd 8 44daemon, 45also known as the IKEv1 key management daemon, 46implements the Internet Key Exchange version 1 (IKEv1) protocol. 47It follows then that references to IKE in this document 48pertain to IKEv1 only, 49and not IKEv2. 50.Pp 51.Xr isakmpd 8 52is used when two 53systems need to automatically set up a pair of Security Associations 54(SAs) for secure communication using IPsec. 55IKEv1 operates in two stages: 56.Pp 57In the first stage (Main or Identity Protection Mode), the two IKE 58daemons establish a secure link between themselves, fully 59authenticating each other and establishing key material for 60encrypting/authenticating future communications between them. 61This step is typically only performed once for every pair of IKE daemons. 62.Pp 63In the second stage (also called Quick Mode), the two IKE daemons 64create the pair of SAs for the parties that wish to communicate using 65IPsec. 66These parties may be the hosts the IKE daemons run on, a host 67and a network behind a firewall, or two networks behind their 68respective firewalls. 69At this stage, the exact parameters of the SAs 70(e.g., algorithms to use, encapsulation mode, lifetime) and the 71identities of the communicating parties (hosts, networks, etc.) are 72specified. 73The reason for the existence of Quick Mode is to allow for fast 74SA setup, once the more heavy-weight Main Mode has been completed. 75Generally, Quick Mode uses the key material derived from Main Mode to 76provide keys to the IPsec transforms to be used. 77.Pp 78Alternatively, a new 79Diffie-Hellman computation may be performed, which significantly slows 80down the exchange, but at the same time provides Perfect Forward 81Secrecy (PFS). 82Briefly, this means that even should an attacker 83manage to break long-term keys used in other sessions (or, 84specifically, if an attacker breaks the Diffie-Hellman exchange 85performed during Main Mode), they will not be able to decrypt this 86traffic. 87Normally, no PFS is provided (the key material used by the 88IPsec SAs established as a result of this exchange will be derived 89from the key material of the Main Mode exchange), allowing for a 90faster Quick Mode exchange (no public key computations). 91.Pp 92IKE proposals are "suggestions" by the initiator of an exchange to the 93responder as to what protocols and attributes should be used on a 94class of packets. 95For example, a given exchange may ask for ESP with 963DES and MD5 and AH with SHA1 (applied successively on the same 97packet), or just ESP with Blowfish and RIPEMD-160. 98The responder 99examines the proposals and determines which of them are acceptable, 100according to policy and any credentials. 101.Pp 102The following paragraphs assume some knowledge of the contents of the 103.Xr keynote 4 104and 105.Xr keynote 5 106man pages. 107.Pp 108In the KeyNote policy model for IPsec, no distinction is currently 109made based on the ordering of AH and ESP in the packet. 110Should this 111change in the future, an appropriate attribute (see below) will be 112added. 113.Pp 114The goal of security policy for IKE is thus to determine, based on 115local policy (provided in the 116.Nm 117file), credentials provided during the IKE exchanges (or obtained 118through other means), the SA attributes proposed during the exchange, 119and perhaps other (side-channel) information, whether a pair of SAs 120should be installed in the system (in fact, whether both the IPsec SAs 121and the flows should be installed). 122For each proposal suggested by or 123to the remote IKE daemon, the KeyNote system is consulted as to 124whether the proposal is acceptable based on local policy (contained in 125.Nm , 126in the form of policy assertions) and remote credentials (e.g., 127KeyNote credentials or X.509 certificates provided by the remote IKE 128daemon). 129.Pp 130.Nm 131is simply a flat 132.Xr ascii 7 133file containing KeyNote policy assertions, separated by blank lines 134(note that KeyNote assertions may not contain blank lines). 135.Nm 136is read when 137.Xr isakmpd 8 138is first started, and every time it receives a 139.Dv SIGHUP 140signal. 141The new policies read will be used for all new Phase 2 (IPsec) 142SAs established from that point on (even if the associated Phase 1 SA 143was already established when the new policies were loaded). 144The policy change will not affect already established Phase 2 SAs. 145.Pp 146For more details on KeyNote assertion format, see 147.Xr keynote 5 . 148Briefly, KeyNote policy assertions used in IKE have the following 149characteristics: 150.Bl -bullet 151.It 152The Authorizer field is typically "POLICY" (but see the examples 153below, for use of policy delegation). 154.It 155The Licensees field can be an expression of passphrases used for 156authentication of the Main Mode exchanges, and/or public keys 157(typically, X.509 certificates), and/or X.509 distinguished names. 158.It 159The Conditions field contains an expression of attributes from the 160IPsec policy action set (see below as well as the keynote syntax man 161page for more details). 162.It 163The ordered return-values set for IPsec policy is "false, true". 164.El 165.Pp 166For an explanation of these fields and their semantics, see 167.Xr keynote 5 . 168.Pp 169For example, the following policy assertion: 170.Bd -literal 171 Authorizer: "POLICY" 172 Licensees: "passphrase:foobar" || "x509-base64:abcd==" || 173 "passphrase-md5-hex:3858f62230ac3c915f300c664312c63f" || 174 "passphrase-sha1-hex:8843d7f92416211de9ebb963ff4ce28125932878" 175 Conditions: app_domain == "IPsec policy" && esp_present == "yes" 176 && esp_enc_alg != "null" -> "true"; 177.Ed 178.Pp 179says that any proposal from a remote host that authenticates using the 180passphrase "foobar" or the public key contained in the X.509 181certificate encoded as "abcd==" will be accepted, as long as it 182contains ESP with a non-null algorithm (i.e., the packet will be 183encrypted). 184The last two authorizers are the MD5 and SHA1 hashes respectively of 185the passphrase "foobar". 186This form may be used instead of the "passphrase:..." one to protect 187the passphrase as included in the policy file (or as distributed in a 188signed credential). 189.Pp 190The following policy assertion: 191.Bd -literal 192 Authorizer: "POLICY" 193 Licensees: "DN:/CN=CA Certificate" 194 Conditions: app_domain == "IPsec policy" && esp_present == "yes" 195 && esp_enc_alg != "null" -> "true"; 196.Ed 197.Pp 198is similar to the previous one, but instead of including a complete 199X.509 credential in the Licensees field, only the X.509 certificate's 200Subject Canonical Name needs to be specified (note that the "DN:" 201prefix is necessary). 202.Pp 203KeyNote credentials have the same format as policy assertions, with 204one difference: the Authorizer field always contains a public key, and 205the assertion is signed (and thus its integrity can be 206cryptographically verified). 207Credentials are used to build chains of delegation of authority. 208They can be exchanged during an IKE exchange, 209or can be retrieved through some out-of-band mechanism (no such 210mechanism is currently supported in this implementation however). 211See 212.Xr isakmpd.conf 5 213on how to specify what credentials to send in an IKE exchange. 214.Pp 215Passphrases that appear in the Licensees field are encoded as the 216string "passphrase:", followed by the passphrase itself 217(case-sensitive). 218Alternatively (and preferably), they may be encoded using the 219"passphrase-md5-hex:" or "passphrase-sha1-hex:" prefixes, followed 220by the 221.Xr md5 1 222or 223.Xr sha1 1 224hash of the passphrase itself, encoded as a hexadecimal string (using 225lower-case letters only). 226.Pp 227When X.509-based authentication is performed in Main Mode, any X.509 228certificates received from the remote IKE daemon are converted to very 229simple KeyNote credentials. 230The conversion is straightforward: the 231issuer of the X.509 certificate becomes the Authorizer of the KeyNote 232credential, the subject becomes the only Licensees entry, while the 233Conditions field simply asserts that the credential is only valid for 234"IPsec policy" use (see the app_domain action attribute below). 235.Pp 236Similarly, any X.509 CA certificates present in the directory pointed 237to by the appropriate 238.Xr isakmpd.conf 5 239entry are converted to such pseudo-credentials. 240This allows one to 241write KeyNote policies that delegate specific authority to CAs (and 242the keys those CAs certify, recursively). 243.Pp 244For more details on KeyNote assertion format, see 245.Xr keynote 5 . 246.Pp 247Information about the proposals, the identity of the remote IKE 248daemon, the packet classes to be protected, etc. are encoded in what 249is called an action set. 250The action set is composed of name-value 251attributes, similar in some ways to shell environment variables. 252These values are initialized by 253.Xr isakmpd 8 254before each query to the KeyNote system, and can be tested against in 255the Conditions field of assertions. 256See 257.Xr keynote 4 258and 259.Xr keynote 5 260for more details on the format and semantics of the Conditions field. 261.Pp 262Note that assertions and credentials can make references to 263non-existent attributes without catastrophic failures (access may be 264denied, depending on the overall structure, but will not be 265accidentally granted). 266One reason for credentials referencing 267non-existent attributes is that they were defined within a specific 268implementation or network only. 269.Pp 270In the following attribute set, IPv4 addresses are encoded as ASCII 271strings in the usual dotted-quad format. 272However, all quads are three digits long. 273For example, the IPv4 address 10.128.1.12 would be encoded as 010.128.001.012. 274Similarly, IPv6 addresses are encoded in the standard x:x:x:x:x:x:x:x 275format, where the 'x's are the hexadecimal values of the eight 16-bit 276pieces of the address. 277All 'x's are four digits long. 278For example, the address 1080:0:12:0:8:800:200C:417A 279would be encoded as 1080:0000:0012:0000:0008:0800:200C:417A. 280.Pp 281The following attributes are currently defined: 282.Bl -tag -width Ds 283.It ah_auth_alg 284One of 285.Va hmac-md5 , 286.Va hmac-sha , 287.Va des-mac , 288.Va kpdk , 289.Va hmac-sha2-256 , 290.Va hmac-sha2-384 , 291.Va hmac-sha2-512 , 292or 293.Va hmac-ripemd . 294based on the authentication method specified in the AH proposal. 295.It ah_ecn, esp_ecn, comp_ecn 296Set to 297.Va yes 298or 299.Va no , 300based on whether ECN was requested for the IPsec tunnel. 301.It ah_encapsulation, esp_encapsulation, comp_encapsulation 302Set to 303.Va tunnel 304or 305.Va transport , 306based on the AH, ESP, and compression proposal. 307.It ah_group_desc, esp_group_desc, comp_group_desc 308The Diffie-Hellman group identifier from the AH, ESP, and compression 309proposal, used for PFS during Quick Mode (see the pfs attribute 310below). 311If more than one of these attributes are set to a value other 312than zero, they should have the same value (in valid IKE proposals). 313Valid values are 1 (768-bit MODP), 2 (1024-bit MODP), 3 (155-bit EC), 3144 (185-bit EC), 5 (1536-bit MODP), 14 (2048-bit MODP), 15 (3072-bit MODP), 31516 (4096-bit MODP), 17 (6144-bit MODP), and 18 (8192-bit MODP). 316.It ah_hash_alg 317One of 318.Va md5 , 319.Va sha , 320.Va ripemd , 321.Va sha2-256 , 322.Va sha2-384 , 323.Va sha2-512 , 324or 325.Va des , 326based on the hash algorithm specified in the AH proposal. 327This attribute describes the generic transform to be used in the AH 328authentication. 329.It ah_key_length, esp_key_length 330The number of key bits to be used by the authentication and encryption 331algorithms respectively (for variable key-size algorithms). 332.It ah_key_rounds, esp_key_rounds 333The number of rounds of the authentication and encryption algorithms 334respectively (for variable round algorithms). 335.It ah_life_kbytes, esp_life_kbytes, comp_life_kbytes 336Set to the lifetime of the AH, ESP, and compression proposal, in 337kbytes of traffic. 338If no lifetime was proposed for the corresponding 339protocol (e.g., there was no proposal for AH), the corresponding 340attribute will be set to zero. 341.It ah_life_seconds, esp_life_seconds, comp_life_seconds 342Set to the lifetime of the AH, ESP, and compression proposal, in 343seconds. 344If no lifetime was proposed for the corresponding protocol 345(e.g., there was no proposal for AH), the corresponding attribute will 346be set to zero. 347.It ah_present, esp_present, comp_present 348Set to 349.Va yes 350if an AH, ESP, or compression proposal was received respectively, 351.Va no 352otherwise. 353.It app_domain 354Always set to 355.Va IPsec policy . 356.It comp_alg 357One of 358.Va oui 359or 360.Va deflate , 361based on the compression algorithm specified in the compression 362proposal. 363.It comp_dict_size 364Specifies the log2 maximum size of the dictionary, according to the 365compression proposal. 366.It comp_private_alg 367Set to an integer specifying the private algorithm in use, according 368to the compression proposal. 369.It doi 370Always set to 371.Va ipsec . 372.It esp_auth_alg 373One of 374.Va hmac-md5 , 375.Va hmac-sha , 376.Va des-mac , 377.Va kpdk , 378.Va hmac-sha2-256 , 379.Va hmac-sha2-384 , 380.Va hmac-sha2-512 , 381or 382.Va hmac-ripemd 383based on the authentication method specified in the ESP proposal. 384.It esp_enc_alg 385One of 386.Va des , 387.Va des-iv64 , 388.Va 3des , 389.Va rc4 , 390.Va idea , 391.Va cast , 392.Va blowfish , 393.Va 3idea , 394.Va des-iv32 , 395.Va rc4 , 396.Va null , 397or 398.Va aes , 399based on the encryption algorithm specified in the ESP proposal. 400.It GMTTimeOfDay 401Set to the UTC date/time, in YYYYMMDDHHmmSS format. 402.It initiator 403Set to 404.Va yes 405if the local daemon is initiating the Phase 2 SA, 406.Va no 407otherwise. 408.It local_negotiation_address 409Set to the IPv4 or IPv6 address of the local interface used by the local IKE 410daemon for this exchange. 411.It LocalTimeOfDay 412Set to the local date/time, in YYYYMMDDHHmmSS format. 413.It pfs 414Set to 415.Va yes 416if a Diffie-Hellman exchange will be performed during this Quick Mode, 417.Va no 418otherwise. 419.It phase_1 420Set to 421.Va aggressive 422if aggressive mode was used to establish the Phase 1 SA, or 423.Va main 424if main mode was used instead. 425.It phase1_group_desc 426The Diffie-Hellman group identifier used in IKE Phase 1. 427Takes the same values as 428.Va ah_group_desc . 429.It remote_filter, local_filter, remote_id 430When the corresponding filter_type specifies an address range or 431subnet, these are set to the upper and lower part of the address 432space separated by a dash ('-') character (if the type specifies a 433single address, they are set to that address). 434.Pp 435For FQDN and User FQDN types, these are set to the respective string. 436For Key ID, these are set to the hexadecimal representation of the 437associated byte string (lower-case letters used) if the Key ID payload 438contains non-printable characters. 439Otherwise, they are set to the respective string. 440.Pp 441For ASN1 DN, these are set to the text encoding of the Distinguished 442Name in the payload sent or received. 443The format is the same as that used in the Licensees field. 444.It remote_filter_addr_lower, local_filter_addr_lower, remote_id_addr_lower 445When the corresponding filter_type is 446.Va IPv4 address 447or 448.Va IPv6 address , 449these contain the respective address. 450For 451.Va IPv4 range 452or 453.Va IPv6 range , 454these contain the lower end of the address range. 455For 456.Va IPv4 subnet 457or 458.Va IPv6 subnet , 459these contain the lowest address in the specified subnet. 460.It remote_filter_addr_upper, local_filter_addr_upper, remote_id_addr_upper 461When the corresponding filter_type is 462.Va IPv4 address 463or 464.Va IPv6 address , 465these contain the respective address. 466For 467.Va IPv4 range 468or 469.Va IPv6 range , 470they contain the upper end of the address range. 471For 472.Va IPv4 subnet 473or 474.Va IPv6 subnet , 475they contain the highest address in the specified subnet. 476.It remote_filter_port, local_filter_port, remote_id_port 477Set to the transport protocol port. 478.It remote_filter_proto, local_filter_proto, remote_id_proto 479Set to 480.Va etherip , 481.Va tcp , 482.Va udp , 483or the transport protocol number, depending on the transport protocol set 484in the IDci, IDcr, and Main Mode peer ID respectively. 485.It remote_filter_type, local_filter_type, remote_id_type 486Set to 487.Va IPv4 address , 488.Va IPv4 range , 489.Va IPv4 subnet , 490.Va IPv6 address , 491.Va IPv6 range , 492.Va IPv6 subnet , 493.Va FQDN , 494.Va User FQDN , 495.Va ASN1 DN , 496.Va ASN1 GN , 497or 498.Va Key ID , 499based on the Quick Mode Initiator ID, Quick Mode Responder ID, and 500Main Mode peer ID respectively. 501.It remote_negotiation_address 502Set to the IPv4 or IPv6 address of the remote IKE daemon. 503.El 504.Sh FILES 505.Bl -tag -width /etc/isakmpd/isakmpd.policy 506.It Pa /etc/isakmpd/isakmpd.policy 507The default 508.Xr isakmpd 8 509policy configuration file. 510.El 511.Sh EXAMPLES 512.Bd -literal 513 Authorizer: "POLICY" 514 Comment: This bare-bones assertion accepts everything 515 516 517 518 Authorizer: "POLICY" 519 Licensees: "passphrase-md5-hex:10838982612aff543e2e62a67c786550" 520 Comment: This policy accepts anyone using shared-secret 521 authentication using the password mekmitasdigoat, 522 and does ESP with some form of encryption (not null). 523 Conditions: app_domain == "IPsec policy" && 524 esp_present == "yes" && 525 esp_enc_alg != "null" -> "true"; 526 527 528 529 Authorizer: "POLICY" 530 Licensees: "subpolicy1" || "subpolicy2" 531 Comment: Delegate to two other sub-policies, so we 532 can manage our policy better. Since these subpolicies 533 are not "owned" by a key (and are thus unsigned), they 534 have to be in isakmpd.policy. 535 Conditions: app_domain == "IPsec policy"; 536 537 538 539 KeyNote-Version: 2 540 Licensees: "passphrase-md5-hex:9c42a1346e333a770904b2a2b37fa7d3" 541 Conditions: esp_present == "yes" -> "true"; 542 Authorizer: "subpolicy1" 543 544 545 546 Conditions: ah_present == "yes" -> 547 { 548 ah_auth_alg == "md5" -> "true"; 549 ah_auth_alg == "sha" && 550 esp_present == "no" -> "true"; 551 }; 552 Licensees: "passphrase:otherpassword" || 553 "passphrase-sha1-hex:f5ed6e4abd30c36a89409b5da7ecb542c9fbf00f" 554 Authorizer: "subpolicy2" 555 556 557 558 keynote-version: 2 559 comment: this is an example of a policy delegating to a CN. 560 authorizer: "POLICY" 561 licensees: "DN:/CN=CA Certificate/emailAddress=ca@foo.bar.com" 562 563 564 565 keynote-version: 2 566 comment: This is an example of a policy delegating to a key. 567 authorizer: "POLICY" 568 licensees: "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ\e 569 FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg\e 570 NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc\e 571 m91cC5jby51azAeFw05OTEwMTEyMjQ5MzhaFw05OTExMTAyMjQ5\e 572 MzhaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8\e 573 GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG\e 574 dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg\e 575 QCxyAte2HEVouXg1Yu+vDihbnjDRn+6k00Rv6cZqbwA3BQ30mC/\e 576 3TFJ09VGXCaM0UKfpnxIpkBYLmOA3FWkKI0RvPU7E1AhKkhC1Ds\e 577 PSBFjYHrB15T5lYzgfwKJCIxTDzZDx2iobUgPa0FRNGVUjpQ4/k\e 578 MJ2BF4Wh7zY3X08rMzsQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA\e 579 DWJ5pbTcE7iKHWLQTMYiz8i9jGi5+Eo1yr1Bab90tgaGQV0zrRH\e 580 jDHgAAy1h8WSXuyQrXfgbx2rnWFPhx9CfmuAXn7sZmQE3mnUqeP\e 581 ZL2dW87jdBGqtoUdNcoz5zKBkC943yasNui/O01MiqgadTThTJH\e 582 d1Pn17LbJC1ZVRNjR5" 583 conditions: app_domain == "IPsec policy" && doi == "ipsec" && 584 pfs == "yes" && esp_present == "yes" && ah_present == "no" && 585 (esp_enc_alg == "3des" || esp_enc_alg == "aes") -> "true"; 586 587 588 589 keynote-version: 2 590 comment: This is an example of a credential, the signature does 591 not really verify (although the keys are real). 592 licensees: "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ\e 593 FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg\e 594 NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc\e 595 m91cC5jby51azAeFw05OTEwMTEyMzA2MjJaFw05OTExMTAyMzA2\e 596 MjJaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8\e 597 GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG\e 598 dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg\e 599 QDaCs+JAB6YRKAVkoi1NkOpE1V3syApjBj0Ahjq5HqYAACo1JhM\e 600 +QsPwuSWCNhBT51HX6G6UzfY3mOUz/vou6MJ/wor8EdeTX4nucx\e 601 NSz/r6XI262aXezAp+GdBviuJZx3Q67ON/IWYrB4QtvihI4bMn5\e 602 E55nF6TKtUMJTdATvs/wIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA\e 603 MaQOSkaiR8id0h6Zo0VSB4HpBnjpWqz1jNG8N4RPN0W8muRA2b9\e 604 85GNP1bkC3fK1ZPpFTB0A76lLn11CfhAf/gV1iz3ELlUHo5J8nx\e 605 Pu6XfsGJm3HsXJOuvOog8Aean4ODo4KInuAsnbLzpGl0d+Jqa5u\e 606 TZUxsyg4QOBwYEU92H" 607 authorizer: "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ\e 608 FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg\e 609 NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc\e 610 m91cC5jby51azAeFw05OTEwMTEyMjQ5MzhaFw05OTExMTAyMjQ5\e 611 MzhaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8\e 612 GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG\e 613 dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg\e 614 QCxyAte2HEVouXg1Yu+vDihbnjDRn+6k00Rv6cZqbwA3BQ30mC/\e 615 3TFJ09VGXCaM0UKfpnxIpkBYLmOA3FWkKI0RvPU7E1AhKkhC1Ds\e 616 PSBFjYHrB15T5lYzgfwKJCIxTDzZDx2iobUgPa0FRNGVUjpQ4/k\e 617 MJ2BF4Wh7zY3X08rMzsQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA\e 618 DWJ5pbTcE7iKHWLQTMYiz8i9jGi5+Eo1yr1Bab90tgaGQV0zrRH\e 619 jDHgAAy1h8WSXuyQrXfgbx2rnWFPhx9CfmuAXn7sZmQE3mnUqeP\e 620 ZL2dW87jdBGqtoUdNcoz5zKBkC943yasNui/O01MiqgadTThTJH\e 621 d1Pn17LbJC1ZVRNjR5" 622conditions: app_domain == "IPsec policy" && doi == "ipsec" && 623 pfs == "yes" && esp_present == "yes" && ah_present == "no" && 624 (esp_enc_alg == "3des" || esp_enc_alg == "aes") -> "true"; 625Signature: "sig-x509-sha1-base64:ql+vrUxv14DcBOQHR2jsbXayq6T\e 626 mmtMiUB745a8rjwSrQwh+KIVDlUrghPnqhSIkWSDi9oWWMbfg\e 627 mkdudZ0wjgeTLMI2NI4GibMMsToakOKMex/0q4cpdpln3DKcQ\e 628 IcjzRv4khDws69FT3QfELjcpShvbLrXmh1Z00OFmxjyqDw=" 629.Ed 630.Sh SEE ALSO 631.Xr ipsec 4 , 632.Xr keynote 4 , 633.Xr keynote 5 , 634.Xr isakmpd 8 635.Sh BUGS 636A more sane way of expressing IPv6 address ranges is needed. 637