LinuxGuruz
  • Last 5 Forum Topics
    Replies
    Views
    Last post


The Web Only This Site
  • BOOKMARK

  • ADD TO FAVORITES

  • REFERENCES


  • MARC

    Mailing list ARChives
    - Search by -
     Subjects
     Authors
     Bodies





    FOLDOC

    Computing Dictionary




  • Text Link Ads






  • LINUX man pages
  • Linux Man Page Viewer


    The following form allows you to view linux man pages.

    Command:

    isakmpd.policy

    
         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 dae-
         mons 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 per-
         formed 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 net-
         work behind a firewall, or two networks behind their respective fire-
         walls.  At this stage, the exact parameters of the SAs (e.g., algorithms
         to use, encapsulation mode, lifetime) and the identities of the communi-
         cating 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
         cies 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 charac-
         teristics:
    
         ?   The Authorizer field is typically "POLICY" (but see the examples
             below, for use of policy delegation).
    
         ?   The Licensees field can be an expression of passphrases used for
             authentication of the Main Mode exchanges, and/or public keys (typi-
             cally, X509 certificates), and/or X509 distinguished names.
    
         ?   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).
    
         ?   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" ||
               "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 nec-
         "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 cer-
         tificates received from the remote IKE daemon are converted to very sim-
         ple 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 initial-
         ized 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 stan-
         dard 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
                  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 pro-
                  tocol (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 corre-
                  sponding protocol (e.g., there was no proposal for AH), the cor-
                  responding attribute will be set to zero.
    
         ah_encapsulation, esp_encapsulation, comp_encapsulation
                  Set to tunnel or transport, based on the AH, ESP, and compres-
                  sion 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
                  (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 represen-
                  tation of the associated byte string (lower-case letters used)
                  if the Key ID payload contains non-printable characters.  Other-
                  wise, they are set to the respective string.
    
                  For ASN1 DN, these are set to the text encoding of the Distin-
                  guished 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
                                      file.
    
         /usr/share/ipsec/isakmpd/policy
                                      A sample isakmpd policy configuration file.
    
    
    

    EXAMPLES

             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
                         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";
    
  • MORE RESOURCE


  • Linux

    The Distributions





    Linux

    The Software





    Linux

    The News



  • MARKETING






  • Toll Free

webmaster@linuxguruz.com
Copyright © 1999 - 2016 by LinuxGuruz