rfc2367.txt

<VC++网络游戏建摸与实现>源代码

                   using this security association. For HARD and SOFT,
                   the number of bytes that may be processed using
                   this security association before it expires.

   sadb_lifetime_addtime
                   For CURRENT, the time, in seconds, when the
                   association was created. For HARD and SOFT, the
                   number of seconds after the creation of the
                   association until it expires.

                   For such time fields, it is assumed that 64-bits is
                   sufficiently large to hold the POSIX time_t value.
                   If this assumption is wrong, this field will have to
                   be revisited.

   sadb_lifetime_usetime
                   For CURRENT, the time, in seconds, when association
                   was first used. For HARD and SOFT, the number of
                   seconds after the first use of the association until
                   it expires.

   The semantics of lifetimes are inclusive-OR, first-to-expire.  This
   means that if values for bytes and time, or multiple times, are
   passed in, the first of these values to be reached will cause a
   lifetime expiration.




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


2.3.3 Address Extension

   The Address extension specifies one or more addresses that are
   associated with a security association. Address extensions for both
   source and destination MUST be present when an Association extension
   is present. The format of an Address extension is:

           struct sadb_address {
                   uint16_t sadb_address_len;
                   uint16_t sadb_address_exttype;
                   uint8_t sadb_address_proto;
                   uint8_t sadb_address_prefixlen;
                   uint16_t sadb_address_reserved;
           };
           /* sizeof(struct sadb_address) == 8 */

           /* followed by some form of struct sockaddr */

   The sockaddr structure SHOULD conform to the sockaddr structure of
   the system implementing PF_KEY. If the system has an sa_len field, so
   SHOULD the sockaddrs in the message. If the system has NO sa_len
   field, the sockaddrs SHOULD NOT have an sa_len field. All non-address
   information in the sockaddrs, such as sin_zero for AF_INET sockaddrs,
   and sin6_flowinfo for AF_INET6 sockaddrs, MUST be zeroed out.  The
   zeroing of ports (e.g. sin_port and sin6_port) MUST be done for all
   messages except for originating SADB_ACQUIRE messages, which SHOULD
   fill them in with ports from the relevant TCP or UDP session which
   generates the ACQUIRE message.  If the ports are non-zero, then the
   sadb_address_proto field, normally zero, MUST be filled in with the
   transport protocol's number.  If the sadb_address_prefixlen is non-
   zero, then the address has a prefix (often used in KM access control
   decisions), with length specified in sadb_address_prefixlen.  These
   additional fields may be useful to KM applications.

   The SRC and DST addresses for a security association MUST be in the
   same protocol family and MUST always be present or absent together in
   a message.  The PROXY address MAY be in a different protocol family,
   and for most security protocols, represents an actual originator of a
   packet.  (For example, the inner-packets's source address in a
   tunnel.)

   The SRC address MUST be a unicast or unspecified (e.g., INADDR_ANY)
   address.  The DST address can be any valid destination address
   (unicast, multicast, or even broadcast). The PROXY address SHOULD be
   a unicast address (there are experimental security protocols where
   PROXY semantics may be different than described above).





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


2.3.4 Key Extension

   The Key extension specifies one or more keys that are associated with
   a security association.  A Key extension will not always be present
   with messages, because of security risks.  The format of a Key
   extension is:

           struct sadb_key {
                   uint16_t sadb_key_len;
                   uint16_t sadb_key_exttype;
                   uint16_t sadb_key_bits;
                   uint16_t sadb_key_reserved;
           };
           /* sizeof(struct sadb_key) == 8 */

           /* followed by the key data */

   sadb_key_bits   The length of the valid key data, in bits. A value of
                   zero in sadb_key_bits MUST cause an error.

   The key extension comes in two varieties. The AUTH version is used
   with authentication keys (e.g. IPsec AH, OSPF MD5) and the ENCRYPT
   version is used with encryption keys (e.g. IPsec ESP).  PF_KEY deals
   only with fully formed cryptographic keys, not with "raw key
   material". For example, when ISAKMP/Oakley is in use, the key
   management daemon is always responsible for transforming the result
   of the Diffie-Hellman computation into distinct fully formed keys
   PRIOR to sending those keys into the kernel via PF_KEY.  This rule is
   made because PF_KEY is designed to support multiple security
   protocols (not just IP Security) and also multiple key management
   schemes including manual keying, which does not have the concept of
   "raw key material".  A clean, protocol-independent interface is
   important for portability to different operating systems as well as
   for portability to different security protocols.

   If an algorithm defines its key to include parity bits (e.g.  DES)
   then the key used with PF_KEY MUST also include those parity bits.
   For example, this means that a single DES key is always a 64-bit
   quantity.

   When a particular security protocol only requires one authentication
   and/or one encryption key, the fully formed key is transmitted using
   the appropriate key extension.  When a particular security protocol
   requires more than one key for the same function (e.g. Triple-DES
   using 2 or 3 keys, and asymmetric algorithms), then those two fully
   formed keys MUST be concatenated together in the order used for
   outbound packet processing. In the case of multiple keys, the
   algorithm MUST be able to determine the lengths of the individual



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


   keys based on the information provided.  The total key length (when
   combined with knowledge of the algorithm in use) usually provides
   sufficient information to make this determination.

   Keys are always passed through the PF_KEY interface in the order that
   they are used for outbound packet processing. For inbound processing,
   the correct order that keys are used might be different from this
   canonical concatenation order used with the PF_KEY interface. It is
   the responsibility of the implementation to use the keys in the
   correct order for both inbound and outbound processing.

   For example, consider a pair of nodes communicating unicast using an
   ESP three-key Triple-DES Security Association. Both the outbound SA
   on the sender node, and the inbound SA on the receiver node will
   contain key-A, followed by key-B, followed by key-C in their
   respective ENCRYPT key extensions. The outbound SA will use key-A
   first, followed by key-B, then key-C when encrypting. The inbound SA
   will use key-C, followed by key-B, then key-A when decrypting.
   (NOTE: We are aware that 3DES is actually encrypt-decrypt-encrypt.)
   The canonical ordering of key-A, key-B, key-C is used for 3DES, and
   should be documented.  The order of "encryption" is the canonical
   order for this example. [Sch96]

   The key data bits are arranged most-significant to least significant.
   For example, a 22-bit key would take up three octets, with the least
   significant two bits not containing key material. Five additional
   octets would then be used for padding to the next 64-bit boundary.

   While not directly related to PF_KEY, there is a user interface issue
   regarding odd-digit hexadecimal representation of keys.  Consider the
   example of the 16-bit number:

           0x123

   That will require two octets of storage. In the absence of other
   information, however, unclear whether the value shown is stored as:

           01 23           OR              12 30

   It is the opinion of the authors that the former (0x123 == 0x0123) is
   the better way to interpret this ambiguity. Extra information (for
   example, specifying 0x0123 or 0x1230, or specifying that this is only
   a twelve-bit number) would solve this problem.








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


2.3.5 Identity Extension

   The Identity extension contains endpoint identities.  This
   information is used by key management to select the identity
   certificate that is used in negotiations. This information may also
   be provided by a kernel to network security aware applications to
   identify the remote entity, possibly for access control purposes.  If
   this extension is not present, key management MUST assume that the
   addresses in the Address extension are the only identities for this
   Security Association. The Identity extension looks like:

           struct sadb_ident {
                   uint16_t sadb_ident_len;
                   uint16_t sadb_ident_exttype;
                   uint16_t sadb_ident_type;
                   uint16_t sadb_ident_reserved;
                   uint64_t sadb_ident_id;
           };
           /* sizeof(struct sadb_ident) == 16 */

           /* followed by the identity string, if present */

   sadb_ident_type The type of identity information that follows.
                   Currently defined identity types are described later
                   in this document.

   sadb_ident_id   An identifier used to aid in the construction of an
                   identity string if none is present.  A POSIX user id
                   value is one such identifier that will be used in this
                   field.  Use of this field is described later in this
                   document.

   A C string containing a textual representation of the identity
   information optionally follows the sadb_ident extension.  The format
   of this string is determined by the value in sadb_ident_type, and is
   described later in this document.

2.3.6 Sensitivity Extension

   The Sensitivity extension contains security labeling information for
   a security association.  If this extension is not present, no
   sensitivity-related data can be obtained from this security
   association.  If this extension is present, then the need for
   explicit security labeling on the packet is obviated.

           struct sadb_sens {
                   uint16_t sadb_sens_len;
                   uint16_t sadb_sens_exttype;



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


                   uint32_t sadb_sens_dpd;
                   uint8_t sadb_sens_sens_level;
                   uint8_t sadb_sens_sens_len;
                   uint8_t sadb_sens_integ_level;
                   uint8_t sadb_sens_integ_len;
                   uint32_t sadb_sens_reserved;
           };
           /* sizeof(struct sadb_sens) == 16 */

           /* followed by:
                   uint64_t sadb_sens_bitmap[sens_len];
                   uint64_t sadb_integ_bitmap[integ_len]; */

   sadb_sens_dpd   Describes the protection domain, which allows
                   interpretation of the levels and compartment
                   bitmaps.
   sadb_sens_sens_level
                   The sensitivity level.
   sadb_sens_sens_len
                   The length, in 64 bit words, of the sensitivity
                   bitmap.
   sadb_sens_integ_level
                   The integrity level.
   sadb_sens_integ_len
                   The length, in 64 bit words, of the integrity
                   bitmap.

   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 */