rfc2479.txt

中、英文RFC文档大全打包下载完全版 .

Network Working Group                                           C. Adams
Request for Comments: 2479                          Entrust Technologies
Category: Informational                                    December 1998


       Independent Data Unit Protection Generic Security Service
              Application Program Interface (IDUP-GSS-API)

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

   The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications
   requiring protection of a generic data unit (such as a file or
   message) in a way which is independent of the protection of any other
   data unit and independent of any concurrent contact with designated
   "receivers" of the data unit.  Thus, it is suitable for applications
   such as secure electronic mail where data needs to be protected
   without any on-line connection with the intended recipient(s) of that
   data.  The protection offered by IDUP includes services such as data
   origin authentication with data integrity, data confidentiality with
   data integrity, and support for non-repudiation services.  Subsequent
   to being protected, the data unit can be transferred to the
   recipient(s) - or to an archive - perhaps to be processed
   ("unprotected") only days or years later.

   Throughout the remainder of this document, the "unit" of data
   described in the above paragraph will be referred to as an IDU
   (Independent Data Unit).  The IDU can be of any size (the application
   may, if it wishes, split the IDU into pieces and have the protection
   computed a piece at a time, but the resulting protection token
   applies to the entire IDU).  However, the primary characteristic of
   an IDU is that it represents a stand-alone unit of data whose
   protection is entirely independent of any other unit of data.  If an
   application protects several IDUs and sends them all to a single
   receiver, the IDUs may be unprotected by that receiver in any order
   over any time span; no logical connection of any kind is implied by
   the protection process itself.





Adams                        Informational                      [Page 1]

RFC 2479                      IDUP-GSS-API                 December 1998


   As with RFC-2078, this IDUP-GSS-API definition provides security
   services to callers in a generic fashion, supportable with a range of
   underlying mechanisms and technologies and hence allowing source-
   level portability of applications to different environments. This
   specification defines IDUP-GSS-API services and primitives at a level
   independent of underlying mechanism and programming language
   environment, and is to be complemented by other, related
   specifications:

      - documents defining specific parameter bindings for particular
        language environments;
      - documents defining token formats, protocols, and procedures to
        be implemented in order to realize IDUP-GSS-API services atop
        particular security mechanisms.

TABLE OF CONTENTS

   1.  IDUP-GSS-API Characteristics and Concepts ..................    3
   1.1.  IDUP-GSS-API Constructs ..................................    5
   1.1.1.  Credentials ............................................    5
   1.1.2.  Tokens .................................................    5
   1.1.3.  Security Environment ...................................    6
   1.1.4.  Mechanism Types ........................................    6
   1.1.5.  Naming .................................................    6
   1.1.6.  Channel Bindings .......................................    6
   1.2.  IDUP-GSS-API Features and Issues .........................    6
   1.2.1.  Status Reporting .......................................    6
   1.2.2.  Per-IDU Security Service Availability ..................    9
   1.2.3.  Per-IDU Replay Detection and Sequencing ................    9
   1.2.4.  Quality of Protection ..................................    9
   1.2.5.  The Provision of Time ..................................   12
   2.  Interface Descriptions .....................................   13
   2.1.  Credential management calls ..............................   14
   2.1.1.  Relationship to GSS-API ................................   14
   2.2.  Environment-level calls ..................................   15
   2.2.1.  Relationship to GSS-API ................................   15
   2.2.2.  IDUP_Establish_Env call ................................   15
   2.2.3.  IDUP_Abolish_Env call ..................................   19
   2.2.4.  IDUP_Inquire_Env call ..................................   19
   2.3.  Per-IDU protection/unprotection calls ....................   20
   2.3.1.  Relationship to GSS-API ................................   20
   2.3.2.  The "SE" Calls .........................................   21
   2.3.3.  The "EV" Calls .........................................   27
   2.3.4.  The "GP" Calls .........................................   36
   2.4.  Special-Purpose calls ....................................   47
   2.4.1.  Relationship to GSS-API ................................   47
   2.4.2.  IDUP_Form_Complete_PIDU ................................   48
   2.5.  Support calls ............................................   49



Adams                        Informational                      [Page 2]

RFC 2479                      IDUP-GSS-API                 December 1998


   2.5.1.  Relationship to GSS-API ................................   49
   2.5.2.  IDUP_Acquire_Cred_With_Auth ............................   49
   2.5.3.  IDUP_Get_Token_Details .................................   50
   2.5.4.  IDUP_Get_Policy_Info ...................................   53
   2.5.5.  IDUP_Cancel_Multibuffer_Op .............................   55
   3.  Related Activities .........................................   55
   4.  Acknowledgments ............................................   56
   5.  Security Considerations ....................................   56
   6.  References       ...........................................   56
   7.  Author's Address ...........................................   56
   Appendix  A Mechanism-Independent Token Format .................   57
   Appendix  B Examples of IDUP Use ...............................   58
   Full Copyright Statement .......................................   70

1. IDUP-GSS-API Characteristics and Concepts

   The paradigm within which IDUP-GSS-API operates is as follows.  An
   IDUP-GSS-API caller is any application that works with IDUs, calling
   on IDUP-GSS-API in order to protect its IDUs with services such as
   data origin authentication with integrity (DOA), confidentiality with
   integrity (CONF), and/or support for non-repudiation (e.g., evidence
   generation, where "evidence" is information that either by itself, or
   when used in conjunction with other information, is used to establish
   proof about an event or action (note:  the evidence itself does not
   necessarily prove truth or existence of something, but contributes to
   establish proof) -- see [ISO/IEC] for fuller discussion regarding
   evidence and its role in various types of non-repudiation).  An
   IDUP-GSS-API caller passes an IDU to, and accepts a token from, its
   local IDUP-GSS-API implementation, transferring the resulting
   protected IDU (P-IDU) to a peer or to any storage medium.  When a P-
   IDU is to be "unprotected", it is passed to an IDUP-GSS-API
   implementation for processing.  The security services available
   through IDUP-GSS-API in this fashion are implementable over a range
   of underlying mechanisms based on secret-key and/or public-key
   cryptographic technologies.

   During the protection operation, the input IDU buffers may be
   modified (for example, the data may be encrypted or encoded in some
   way) or may remain unchanged.  In any case, the result is termed a
   "M-IDU" (Modified IDU) in order to distinguish it from the original
   IDU.  Depending on the desire of the calling application and the
   capabilities of the underlying IDUP mechanism, the output produced by
   the protection processing may or may not encapsulate the M-IDU. Thus,
   the P-IDU may be the contents of a single output parameter (if
   encapsulation is done) or may be the logical concatenation of an
   unencapsulated token parameter and a M-IDU parameter (if
   encapsulation is not done).  In the latter case, the protecting
   application may choose whatever method it wishes to concatenate or



Adams                        Informational                      [Page 3]

RFC 2479                      IDUP-GSS-API                 December 1998


   combine the unencapsulated token and the M-IDU into a P-IDU, provided
   the unprotecting application knows how to de-couple the P-IDU back
   into its component parts prior to calling the IDUP unprotection set
   of functions.

   It is expected that any output buffer returned by IDUP (i.e., P-IDU
   or portion thereof) is ready for immediate transmission to the
   intended receiver(s) by the calling application, if this is desired.
   In other words, an application wishing to transmit data buffers as
   they appear from IDUP should not be unduly restricted from doing so
   by the underlying mechanism.

   The IDUP-GSS-API separates the operation of initializing a security
   environment (the IDUP_Establish_Env() call) from the operations of
   providing per-IDU protection, for IDUs subsequently protected in
   conjunction with that environment. Per-IDU protection and
   unprotection calls provide DOA, CONF, evidence, and other services,
   as requested by the calling application and as supported by the
   underlying mechanism.

   The following paragraphs provide an example illustrating the
   dataflows involved in the use of the IDUP-GSS-API by the sender and
   receiver of a P-IDU in a mechanism-independent fashion.  The example
   assumes that credential acquisition has already been completed by
   both sides.  Furthermore, the example does not cover all possible
   options available in the protection/unprotection calls.

      The sender first calls IDUP_Establish_Env() to establish a
      security environment.  Then, for the IDU to be protected the
      sender calls the appropriate protection calls (SE, EV, or GP) to
      perform the IDU protection.  The resulting P-IDU, which may
      (depending on whether or not encapsulation was chosen/available)
      be either the token itself or the logical concatenation of the
      token and the M-IDU, is now ready to be sent to the target.  The
      sender then calls IDUP_Abolish_Env() to flush all environment-
      specific information.

      The receiver first calls IDUP_Establish_Env() to establish a
      security environment in order to unprotect the P-IDU.  Then, for
      the received P-IDU the receiver calls the appropriate unprotection
      calls (SE, EV, or GP (known a priori, or possibly determined
      through the use of the IDUP_Get_token_details call)) to perform
      the P-IDU unprotection.  The receiver then calls
      IDUP_Abolish_Env() to flush all environment-specific information.

   It is important to note that absolutely no synchronization is implied
   or expected between the data buffer size used by the sender as input
   to the protection calls, the data buffer size used by the receiver as



Adams                        Informational                      [Page 4]

RFC 2479                      IDUP-GSS-API                 December 1998


   input to the unprotection calls, and the block sizes required by the
   underlying protection algorithms (integrity and confidentiality). All
   these sizes are meant to be independent; furthermore, the data buffer
   sizes used for the protection and unprotection calls are purely a
   function of the local environment where the calls are made.

   The IDUP-GSS-API design assumes and addresses several basic goals,
   including the following.

      Mechanism independence:  The IDUP-GSS-API defines an interface to
      cryptographically implemented security services at a generic level
      which is independent of particular underlying mechanisms. For
      example, IDUP-GSS-API-provided services can be implemented by
      secret-key technologies or public-key approaches.

      Protocol environment independence: The IDUP-GSS-API is independent
      of the communications protocol suites which may be used to
      transfer P-IDUs, permitting use in a broad range of protocol
      environments.

      Protocol association independence: The IDUP-GSS-API's security
      environment construct has nothing whatever to do with
      communications protocol association constructs, so that IDUP-GSS-
      API services can be invoked by applications, wholly independent of
      protocol associations.

      Suitability for a range of implementation placements: IDUP-GSS-API
      clients are not constrained to reside within any Trusted Computing
      Base (TCB) perimeter defined on a system where the IDUP-GSS-API is
      implemented; security services are specified in a manner suitable
      for both intra-TCB and extra-TCB callers.

1.1. IDUP-GSS-API Constructs

   This section describes the basic elements comprising the IDUP-GSS-
   API.

1.1.1.  Credentials

   Credentials in IDUP-GSS-API are to be understood and used as
   described in GSS-API [RFC-2078].

1.1.2. Tokens

   Tokens in IDUP-GSS-API are to be understood and used as described in
   GSS-API [RFC-2078] with the exception that there are no context-level
   tokens generated by IDUP-GSS-API.  The IDUP-GSS-API token may
   (depending on the underlying mechanism) encapsulate the M-IDU or may



Adams                        Informational                      [Page 5]

RFC 2479                      IDUP-GSS-API                 December 1998


   be logically concatenated with the M-IDU prior to transfer to a
   target; furthermore, for some evidence services the token may be sent
   independently of any other data transfer.

1.1.3.  Security Environment

   The "security environment" in IDUP-GSS-API is entirely different from
   the concept of security contexts used in GSS-API [RFC-2078].  Here, a
   security environment exists within a calling application (that is, it
   is purely local to the caller) for the purpose of protecting or
   unprotecting one or more IDUs using a particular caller credential or
   set of credentials.  In GSS-API, on the other hand, a security
   context exists between peers (the initiator and the target) for the
   purpose of protecting, in real time, the data that is exchanged
   between them.  Although they are different concepts, the env_handle
   in IDUP-GSS-API is similar to the context_handle in GSS-API in that
   it is a convenient way of tying together the entire process of
   protecting or unprotecting one or more IDUs using a particular
   underlying mechanism.  As with the GSS-API security contexts, a
   caller can initiate and maintain multiple environments using the same
   or different credentials.

1.1.4.  Mechanism Types

   Mechanism types in IDUP-GSS-API are to be understood and used as
   described in GSS-API [RFC-2078].

1.1.5.  Naming

   Naming in IDUP-GSS-API is to be understood and used as described in