📄 rfc2479.txt
字号:
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -