rfc2367.txt

RFC 的详细文档！

   This sensitivity extension is designed to support the Bell-LaPadula
   [BL74] security model used in compartmented-mode or multi-level
   secure systems, the Clark-Wilson [CW87] commercial security model,
   and/or the Biba integrity model [Biba77]. These formal models can be
   used to implement a wide variety of security policies. The definition
   of a particular security policy is outside the scope of this
   document.  Each of the bitmaps MUST be padded to a 64-bit boundary if
   they are not implicitly 64-bit aligned.

2.3.7 Proposal Extension

   The Proposal extension contains a "proposed situation" of algorithm
   preferences.  It looks like:

           struct sadb_prop {
                   uint16_t sadb_prop_len;
                   uint16_t sadb_prop_exttype;
                   uint8_t sadb_prop_replay;
                   uint8_t sadb_prop_reserved[3];
           };
           /* sizeof(struct sadb_prop) == 8 */



McDonald, et. al.            Informational                     [Page 22]

RFC 2367               PF_KEY Key Management API               July 1998


           /* followed by:
              struct sadb_comb sadb_combs[(sadb_prop_len *
                  sizeof(uint64_t) - sizeof(struct sadb_prop)) /
                  sizeof(struct sadb_comb)]; */

   Following the header is a list of proposed parameter combinations in
   preferential order.  The values in these fields have the same
   definition as the fields those values will move into if the
   combination is chosen.

       NOTE: Some algorithms in some security protocols will have
             variable IV lengths per algorithm.  Variable length IVs
             are not supported by PF_KEY v2.  If they were, however,
             proposed IV lengths would go in the Proposal Extension.

   These combinations look like:

           struct sadb_comb {
                   uint8_t sadb_comb_auth;
                   uint8_t sadb_comb_encrypt;
                   uint16_t sadb_comb_flags;
                   uint16_t sadb_comb_auth_minbits;
                   uint16_t sadb_comb_auth_maxbits;
                   uint16_t sadb_comb_encrypt_minbits;
                   uint16_t sadb_comb_encrypt_maxbits;
                   uint32_t sadb_comb_reserved;
                   uint32_t sadb_comb_soft_allocations;
                   uint32_t sadb_comb_hard_allocations;
                   uint64_t sadb_comb_soft_bytes;
                   uint64_t sadb_comb_hard_bytes;
                   uint64_t sadb_comb_soft_addtime;
                   uint64_t sadb_comb_hard_addtime;
                   uint64_t sadb_comb_soft_usetime;
                   uint64_t sadb_comb_hard_usetime;
           };

           /* sizeof(struct sadb_comb) == 72 */

   sadb_comb_auth  If this combination is accepted, this will be the
                   value of sadb_sa_auth.

   sadb_comb_encrypt
                   If this combination is accepted, this will be the
                   value of sadb_sa_encrypt.







McDonald, et. al.            Informational                     [Page 23]

RFC 2367               PF_KEY Key Management API               July 1998


   sadb_comb_auth_minbits;
   sadb_comb_auth_maxbits;
                   The minimum and maximum acceptable authentication
                   key lengths, respectably, in bits. If sadb_comb_auth
                   is zero, both of these values MUST be zero. If
                   sadb_comb_auth is nonzero, both of these values MUST
                   be nonzero. If this combination is accepted, a value
                   between these (inclusive) will be stored in the
                   sadb_key_bits field of KEY_AUTH. The minimum MUST
                   NOT be greater than the maximum.

   sadb_comb_encrypt_minbits;
   sadb_comb_encrypt_maxbits;
                   The minimum and maximum acceptable encryption key
                   lengths, respectably, in bits. If sadb_comb_encrypt
                   is zero, both of these values MUST be zero. If
                   sadb_comb_encrypt is nonzero, both of these values
                   MUST be nonzero. If this combination is accepted, a
                   value between these (inclusive) will be stored in
                   the sadb_key_bits field of KEY_ENCRYPT. The minimum
                   MUST NOT be greater than the maximum.

   sadb_comb_soft_allocations
   sadb_comb_hard_allocations
                   If this combination is accepted, these are proposed
                   values of sadb_lifetime_allocations in the SOFT and
                   HARD lifetimes, respectively.

   sadb_comb_soft_bytes
   sadb_comb_hard_bytes
                   If this combination is accepted, these are proposed
                   values of sadb_lifetime_bytes in the SOFT and HARD
                   lifetimes, respectively.

   sadb_comb_soft_addtime
   sadb_comb_hard_addtime
                   If this combination is accepted, these are proposed
                   values of sadb_lifetime_addtime in the SOFT and HARD
                   lifetimes, respectively.

   sadb_comb_soft_usetime
   sadb_comb_hard_usetime
                   If this combination is accepted, these are proposed
                   values of sadb_lifetime_usetime in the SOFT and HARD
                   lifetimes, respectively.






McDonald, et. al.            Informational                     [Page 24]

RFC 2367               PF_KEY Key Management API               July 1998


   Each combination has an authentication and encryption algorithm,
   which may be 0, indicating none.  A combination's flags are the same
   as the flags in the Association extension.  The minimum and maximum
   key lengths (which are in bits) are derived from possible a priori
   policy decisions, along with basic properties of the algorithm.
   Lifetime attributes are also included in a combination, as some
   algorithms may know something about their lifetimes and can suggest
   lifetime limits.

2.3.8 Supported Algorithms Extension

   The Supported Algorithms extension contains a list of all algorithms
   supported by the system. This tells key management what algorithms it
   can negotiate. Available authentication algorithms are listed in the
   SUPPORTED_AUTH extension and available encryption algorithms are
   listed in the SUPPORTED_ENCRYPT extension. The format of these
   extensions is:

           struct sadb_supported {
                   uint16_t sadb_supported_len;
                   uint16_t sadb_supported_exttype;
                   uint32_t sadb_supported_reserved;
           };
           /* sizeof(struct sadb_supported) == 8 */

           /* followed by:
              struct sadb_alg sadb_algs[(sadb_supported_len *
                  sizeof(uint64_t) - sizeof(struct sadb_supported)) /
                  sizeof(struct sadb_alg)]; */

     This header is followed by one or more algorithm  descriptions.  An
   algorithm description looks like:

           struct sadb_alg {
                   uint8_t sadb_alg_id;
                   uint8_t sadb_alg_ivlen;
                   uint16_t sadb_alg_minbits;
                   uint16_t sadb_alg_maxbits;
                   uint16_t sadb_alg_reserved;
           };
           /* sizeof(struct sadb_alg) == 8 */

   sadb_alg_id    The algorithm identification value for this
                  algorithm. This is the value that is stored in
                  sadb_sa_auth or sadb_sa_encrypt if this algorithm is
                  selected.





McDonald, et. al.            Informational                     [Page 25]

RFC 2367               PF_KEY Key Management API               July 1998


   sadb_alg_ivlen The length of the initialization vector to be used
                  for the algorithm. If an IV is not needed, this
                  value MUST be set to zero.

   sadb_alg_minbits
                   The minimum acceptable key length, in bits. A value
                   of zero is invalid.

   sadb_alg_maxbits
                   The maximum acceptable key length, in bits. A value
                   of zero is invalid. The minimum MUST NOT be greater
                   than the maximum.

2.3.9 SPI Range Extension

   One PF_KEY message, SADB_GETSPI, might need a range of acceptable SPI
   values.  This extension performs such a function.

           struct sadb_spirange {
                   uint16_t sadb_spirange_len;
                   uint16_t sadb_spirange_exttype;
                   uint32_t sadb_spirange_min;
                   uint32_t sadb_spirange_max;
                   uint32_t sadb_spirange_reserved;
           };
           /* sizeof(struct sadb_spirange) == 16 */

   sadb_spirange_min
                   The minimum acceptable SPI value.

   sadb_spirange_max
                   The maximum acceptable SPI value. The maximum MUST
                   be greater than or equal to the minimum.


















McDonald, et. al.            Informational                     [Page 26]

RFC 2367               PF_KEY Key Management API               July 1998


2.4 Illustration of Message Layout

   The following shows how the octets are laid out in a PF_KEY message.
   Optional fields are indicated as such.

   The base header is as follows:

     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
    +---------------+---------------+---------------+---------------+
    |  ...version   | sadb_msg_type | sadb_msg_errno| ...msg_satype |
    +---------------+---------------+---------------+---------------+
    |          sadb_msg_len         |       sadb_msg_reserved       |
    +---------------+---------------+---------------+---------------+
    |                         sadb_msg_seq                          |
    +---------------+---------------+---------------+---------------+
    |                         sadb_msg_pid                          |
    +---------------+---------------+---------------+---------------+

   The base header may be followed by one or more of the following
   extension fields, depending on the values of various base header
   fields.  The following fields are ordered such that if they appear,
   they SHOULD appear in the order presented below.

   An extension field MUST not be repeated.  If there is a situation
   where an extension MUST be repeated, it should be brought to the
   attention of the authors.

   The Association extension

       0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
       +---------------+---------------+---------------+---------------+
       |          sadb_sa_len          |        sadb_sa_exttype        |
       +---------------+---------------+---------------+---------------+
       |                          sadb_sa_spi                          |
       +---------------+---------------+---------------+---------------+
       |   ...replay   | sadb_sa_state | sadb_sa_auth  |sadb_sa_encrypt|
       +---------------+---------------+---------------+---------------+
       |                         sadb_sa_flags                         |
       +---------------+---------------+---------------+---------------+

   The Lifetime extension

       +---------------+---------------+---------------+---------------+
       |         sadb_lifetime_le