rfc2367.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       D. McDonald
Request for Comments: 2367                                      C. Metz
Category: Informational                                         B. Phan
                                                              July 1998


                  PF_KEY Key Management API, Version 2

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   A generic key management API that can be used not only for IP
   Security [Atk95a] [Atk95b] [Atk95c] but also for other network
   security services is presented in this document.  Version 1 of this
   API was implemented inside 4.4-Lite BSD as part of the U. S. Naval
   Research Laboratory's freely distributable and usable IPv6 and IPsec
   implementation[AMPMC96].  It is documented here for the benefit of
   others who might also adopt and use the API, thus providing increased
   portability of key management applications (e.g. a manual keying
   application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], a
   Photuris daemon, or a SKIP certificate discovery protocol daemon).

Table of Contents

   1      Introduction .............................................  3
   1.1    Terminology ..............................................  3
   1.2    Conceptual Model .........................................  4
   1.3    PF_KEY Socket Definition .................................  8
   1.4    Overview of PF_KEY Messaging Behavior ....................  8
   1.5    Common PF_KEY Operations .................................  9
   1.6    Differences Between PF_KEY and PF_ROUTE .................. 10
   1.7    Name Space ............................................... 11
   1.8    On Manual Keying ..........................................11
   2      PF_KEY Message Format .................................... 11
   2.1    Base Message Header Format ............................... 12
   2.2    Alignment of Headers and Extension Headers ............... 14
   2.3    Additional Message Fields ................................ 14
   2.3.1  Association Extension .................................... 15
   2.3.2  Lifetime Extension ....................................... 16



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


   2.3.3  Address Extension ........................................ 18
   2.3.4  Key Extension ............................................ 19
   2.3.5  Identity Extension ....................................... 21
   2.3.6  Sensitivity Extension .................................... 21
   2.3.7  Proposal Extension ....................................... 22
   2.3.8  Supported Algorithms Extension ........................... 25
   2.3.9  SPI Range Extension ...................................... 26
   2.4    Illustration of Message Layout ........................... 27
   3      Symbolic Names ........................................... 30
   3.1    Message Types ............................................ 31
   3.1.1  SADB_GETSPI .............................................. 32
   3.1.2  SADB_UPDATE .............................................. 33
   3.1.3  SADB_ADD ................................................. 34
   3.1.4  SADB_DELETE .............................................. 35
   3.1.5  SADB_GET ................................................. 36
   3.1.6  SADB_ACQUIRE ............................................. 36
   3.1.7  SADB_REGISTER ............................................ 38
   3.1.8  SADB_EXPIRE .............................................. 39
   3.1.9  SADB_FLUSH ............................................... 40
   3.1.10 SADB_DUMP ................................................ 40
   3.2    Security Association Flags ............................... 41
   3.3    Security Association States .............................. 41
   3.4    Security Association Types ............................... 41
   3.5    Algorithm Types .......................................... 42
   3.6    Extension Header Values .................................. 43
   3.7    Identity Extension Values ................................ 44
   3.8    Sensitivity Extension Values ............................. 45
   3.9    Proposal Extension Values ................................ 45
   4      Future Directions ........................................ 45
   5      Examples ................................................. 45
   5.1    Simple IP Security Example ............................... 46
   5.2    Proxy IP Security Example ................................ 47
   5.3    OSPF Security Example .................................... 50
   5.4    Miscellaneous ............................................ 50
   6      Security Considerations .................................. 51
          Acknowledgments ............,............................. 52
          References ............................................... 52
          Disclaimer ............................................... 54
          Authors' Addresses ....................................... 54
   A      Promiscuous Send/Receive Extension ....................... 55
   B      Passive Change Message Extension ......................... 57
   C      Key Management Private Data Extension .................... 58
   D      Sample Header File ....................................... 59
   E      Change Log ............................................... 64
   F      Full Copyright Statement ................................. 68






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


1 Introduction

   PF_KEY is a new socket protocol family used by trusted privileged key
   management applications to communicate with an operating system's key
   management internals (referred to here as the "Key Engine" or the
   Security Association Database (SADB)).  The Key Engine and its
   structures incorporate the required security attributes for a session
   and are instances of the "Security Association" (SA) concept
   described in [Atk95a].  The names PF_KEY and Key Engine thus refer to
   more than cryptographic keys and are retained for consistency with
   the traditional phrase, "Key Management".

   PF_KEY is derived in part from the BSD routing socket, PF_ROUTE.
   [Skl91] This document describes Version 2 of PF_KEY. Version 1 was
   implemented in the first five alpha test versions of the NRL
   IPv6+IPsec Software Distribution for 4.4-Lite BSD UNIX and the Cisco
   ISAKMP/Oakley key management daemon.  Version 2 extends and refines
   this interface. Theoretically, the messages defined in this document
   could be used in a non-socket context (e.g.  between two directly
   communicating user-level processes), but this document will not
   discuss in detail such possibilities.

   Security policy is deliberately omitted from this interface. PF_KEY
   is not a mechanism for tuning systemwide security policy, nor is it
   intended to enforce any sort of key management policy. The developers
   of PF_KEY believe that it is important to separate security
   mechanisms (such as PF_KEY) from security policies.  This permits a
   single mechanism to more easily support multiple policies.

1.1 Terminology

   Even though this document is not intended to be an actual Internet
   standard, the words that are used to define the significance of
   particular features of this interface are usually capitalized.  Some
   of these words, including MUST, MAY, and SHOULD, are detailed in
   [Bra97].

   - CONFORMANCE and COMPLIANCE

   Conformance to this specification has the same meaning as compliance
   to this specification.  In either case, the mandatory-to-implement,
   or MUST, items MUST be fully implemented as specified here.  If any
   mandatory item is not implemented as specified here, that
   implementation is not conforming and not compliant with this
   specification.






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


   This specification also uses many terms that are commonly used in the
   context of network security.  Other documents provide more
   definitions and background information on these [VK83, HA94, Atk95a].
   Two terms deserve special mention:

   - (Encryption/Authentication) Algorithm

   For PF_KEY purposes, an algorithm, whether encryption or
   authentication, is the set of operations performed on a packet to
   complete authentication or encryption as indicated by the SA type.  A
   PF_KEY algorithm MAY consist of more than one cryptographic
   algorithm. Another possibility is that the same basic cryptographic
   algorithm may be applied with different modes of operation or some
   other implementation difference. These differences, henceforth called
   _algorithm differentiators_, distinguish between different PF_KEY
   algorithms, and options to the same algorithm.  Algorithm
   differentiators will often cause fundamentally different security
   properties.

   For example, both DES and 3DES use the same cryptographic algorithm,
   but they are used differently and have different security properties.
   The triple-application of DES is considered an algorithm
   differentiator.  There are therefore separate PF_KEY algorithms for
   DES and 3DES. Keyed-MD5 and HMAC-MD5 use the same hash function, but
   construct their message authentication codes differently. The use of
   HMAC is an algorithm differentiator.  DES-ECB and DES-CBC are the
   same cryptographic algorithm, but use a different mode. Mode (e.g.,
   chaining vs. code-book) is an algorithm differentiator. Blowfish with
   a 128-bit key, however, is similar to Blowfish with a 384-bit key,
   because the algorithm's workings are otherwise the same and therefore
   the key length is not an algorithm differentiator.

   In terms of IP Security, a general rule of thumb is that whatever
   might be labeled the "encryption" part of an ESP transform is
   probably a PF_KEY encryption algorithm. Whatever might be labelled
   the "authentication" part of an AH or ESP transform is probably a
   PF_KEY authentication algorithm.

1.2 Conceptual Model

   This section describes the conceptual model of an operating system
   that implements the PF_KEY key management application programming
   interface. This section is intended to provide background material
   useful to understand the rest of this document.  Presentation of this
   conceptual model does not constrain a PF_KEY implementation to
   strictly adhere to the conceptual components discussed in this
   subsection.




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


   Key management is most commonly implemented in whole or in part at
   the application layer.  For example, the ISAKMP/Oakley, GKMP, and
   Photuris proposals for IPsec key management are all application-layer
   protocols.  Manual keying is also done at the application layer.
   Even parts of the SKIP IP-layer keying proposal can be implemented at
   the application layer.  Figure 1 shows the relationship between a Key
   Management daemon and PF_KEY.  Key management daemons use PF_KEY to
   communicate with the Key Engine and use PF_INET (or PF_INET6 in the
   case of IPv6) to communicate, via the network, with a remote key
   management entity.

   The "Key Engine" or "Security Association Database (SADB)" is a
   logical entity in the kernel that stores, updates, and deletes
   Security Association data for various security protocols.  There are
   logical interfaces within the kernel (e.g.  getassocbyspi(),
   getassocbysocket()) that security protocols inside the kernel (e.g.
   IP Security, aka IPsec) use to request and obtain Security
   Associations.

   In the case of IPsec, if by policy a particular outbound packet needs
   processing, then the IPsec implementation requests an appropriate
   Security Association from the Key Engine via the kernel-internal
   interface.  If the Key Engine has an appropriate SA, it allocates the
   SA to this session (marking it as used) and returns the SA to the
   IPsec implementation for use.  If the Key Engine has no such SA but a
   key management application has previously indicated (via a PF_KEY
   SADB_REGISTER message) that it can obtain such SAs, then the Key
   Engine requests that such an SA be created (via a PF_KEY SADB_ACQUIRE
   message).  When the key management daemon creates a new SA, it places
   it into the Key Engine for future use.





















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


                     +---------------+
                     |Key Mgmt Daemon|
                     +---------------+
                       |           |
                       |           |
                       |           |                   Applications
               ======[PF_KEY]====[PF_INET]==========================
                       |           |                   OS Kernel
               +------------+   +-----------------+
               | Key Engine |   | TCP/IP,         |
               |  or  SADB  |---| including IPsec |
               +------------+   |                 |
                                +-----------------+
                                       |
                                   +-----------+
                                   | Network   |
                                   | Interface |
                                   +-----------+

              Figure 1: Relationship of Key Mgmt to PF_KEY

   For performance reasons, some security protocols (e.g. IP Security)