idnits 2.17.1 draft-ietf-cat-idup-gss-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1454 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-1508]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 374 has weird spacing: '..._object impo...' == Line 375 has weird spacing: '..._object expo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 31, 1995) is 10619 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KRB5' is mentioned on line 1092, but not defined == Missing Reference: 'SPKM' is mentioned on line 1093, but not defined == Missing Reference: 'APPLICATION 0' is mentioned on line 1293, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MSP' ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Obsolete normative reference: RFC 1508 (Obsoleted by RFC 2078) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Adams, Bell-Northern Research 2 draft-ietf-cat-idup-gss-01.txt March 31, 1995 4 Independent Data Unit Protection Generic Security Service 5 Application Program Interface (IDUP-GSS-API) 7 STATUS OF THIS MEMO 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by 16 other documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as 18 "work in progress." 20 To learn the current status of any Internet Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 Comments on this document should be sent to "cat-ietf@mit.edu", the 27 IETF Common Authentication Technology WG discussion list. 29 ABSTRACT 31 The IDUP-GSS-API (previously known as IOP-GSS-API) extends the 32 GSS-API [RFC-1508] for applications requiring protection of a generic 33 data unit (such as a file or message) in a way which is independent 34 of the protection of any other data unit and independent of any 35 concurrent contact with designated "receivers" of the data unit. 36 Thus, it is suitable for applications such as secure electronic mail 37 where data needs to be protected without any on-line connection with 38 the intended recipient(s) of that data. Subsequent to being 39 protected, the data unit can be transferred to the recipient(s) - or 40 to an archive - perhaps to be processed only days or years later. 42 Throughout the remainder of this document, the "unit" of data 43 described in the above paragraph will be referred to as an IDU 44 (Independent Data Unit). The IDU can be of any size (the application 45 may, if it wishes, split the IDU into pieces and have the protection 46 computed a piece at a time, but the resulting protection token 47 applies to the entire IDU). However, the primary characteristic of 48 an IDU is that it represents a stand-alone unit of data whose 49 protection is entirely independent of any other unit of data. If an 50 application protects several IDUs and sends them all to a single 51 receiver, the IDUs may be unprotected by that receiver in any order 52 over any time span; no logical connection of any kind is implied by 53 the protection process itself. 55 Adams Document Expiration: 30 Sept. 1995 1 56 As with RFC-1508, this IDUP-GSS-API definition provides security 57 services to callers in a generic fashion, supportable with a range of 58 underlying mechanisms and technologies and hence allowing source- 59 level portability of applications to different environments. This 60 specification defines IDUP-GSS-API services and primitives at a level 61 independent of underlying mechanism and programming language environ- 62 ment, and is to be complemented by other, related specifications: 64 - documents defining specific parameter bindings for particular 65 language environments; 66 - documents defining token formats, protocols, and procedures to 67 be implemented in order to realize IDUP-GSS-API services atop 68 particular security mechanisms. 70 TABLE OF CONTENTS 71 1. IDUP-GSS-API Characteristics and Concepts ................... 3 72 1.1. IDUP-GSS-API Constructs ................................... 4 73 1.1.1. Credentials ............................................ 4 74 1.1.2. Tokens ................................................. 4 75 1.1.3. Security Environment ................................... 5 76 1.1.4. Mechanism Types ........................................ 5 77 1.1.5. Naming ................................................. 5 78 1.1.6. Channel Bindings ....................................... 5 79 1.2. IDUP-GSS-API Features and Issues ......................... 5 80 1.2.1. Status Reporting ....................................... 5 81 1.2.2. Per-IDU Security Service Availability .................. 6 82 1.2.3. Per-IDU Replay Detection and Sequencing ................ 6 83 1.2.4. Quality of Protection .................................. 6 84 2. Interface Descriptions ...................................... 7 85 2.1. Credential management calls .............................. 8 86 2.1.1. Relationship to GSS-API ................................ 8 87 2.2. Environment-level calls .................................. 8 88 2.2.1. Relationship to GSS-API ................................ 8 89 2.2.2. IDUP_Establish_Env call ................................ 9 90 2.2.3. IDUP_Abolish_Env call .................................. 11 91 2.2.4. IDUP_Inquire_Env call .................................. 11 92 2.3. Per-IDU calls ............................................ 12 93 2.3.1. Relationship to GSS-API ................................ 12 94 2.3.2. IDUP_Start_Protect ..................................... 13 95 2.3.3. IDUP_Protect ........................................... 15 96 2.3.4. IDUP_End_Protect ....................................... 15 97 2.3.5. IDUP_Start_Unprotect ................................... 16 98 2.3.6. IDUP_Unprotect ......................................... 18 99 2.3.7. IDUP_End_Unprotect ..................................... 18 100 2.3.8. IDUP_Process_Receipt ................................... 19 101 2.4. Support calls ............................................ 20 102 2.4.1. Relationship to GSS-API ................................ 20 103 2.4.2. IDUP_Parse_token call .................................. 20 104 3. Mechanism-Specific Example Scenarios ........................ 22 105 3.1. PEM-compliant file protection ............................ 22 106 3.2. Signed-MSP-compliant file protection ..................... 23 107 4. Related Activities .......................................... 23 108 5. Acknowledgments ............................................. 24 109 6. Security Considerations ..................................... 24 110 7. References ............................................ 24 111 8. Author's Address ............................................ 24 112 Appendix A, B .................................................. 25 113 Adams Document Expiration: 30 Sept. 1995 2 115 1. IDUP-GSS-API Characteristics and Concepts 117 The operational paradigm in which IDUP-GSS-API operates is as 118 follows. An IDUP-GSS-API caller is any application which works with 119 IDUs, calling on IDUP-GSS-API in order to protect its IDUs with 120 origin authentication, integrity, confidentiality, and/or (support 121 for) non-repudiation security services. An IDUP-GSS-API caller 122 accepts tokens provided to it by its local IDUP-GSS-API 123 implementation, logically concatenates the token(s) and the IDU to 124 create a protected IDU (P-IDU), and transfers the P-IDU to a peer or 125 to any storage medium. When the P-IDU is to be "unprotected", the 126 token(s) and the IDU must be passed to an IDUP-GSS-API implementation 127 for processing. The security services available through IDUP-GSS-API 128 in this fashion are implementable over a range of underlying 129 mechanisms based on secret-key and public-key cryptographic 130 technologies. Note that the protecting application may choose 131 whatever method it wishes to concatenate or combine the token(s) and 132 the IDU into a P-IDU, but the unprotecting application must know how 133 to de-couple the P-IDU back into its component parts prior to calling 134 the IDUP unprotection set of functions. 136 The IDUP-GSS-API separates the operation of initializing a security 137 environment (the IDUP_Establish_Env() call) from the operations of 138 providing per-IDU protection, for IDUs subsequently protected in 139 conjunction with that environment. Per-IDU protection and 140 unprotection calls provide the data origin authentication / data 141 integrity services, or confidentiality services, or both, as a caller 142 option. Additional calls provide supportive functions to the 143 IDUP-GSS-API's users. 145 The following paragraphs provide an example illustrating the 146 dataflows involved in use of the IDUP-GSS-API by the sender and 147 receiver of a P-IDU in a mechanism-independent fashion. The example 148 assumes that credential acquisition has already been completed by 149 both sides. 151 The sender first calls IDUP_Establish_Env() to establish a 152 security environment. Then, for the IDU to be protected the 153 sender calls IDUP_Start_Protect(), IDUP_Protect() for each buffer 154 of data, and IDUP_End_Protect() to complete the IDU protection. 155 The prot_token output by IDUP_End_Protect() and the IDU (which had 156 confidentiality applied if this was requested in 157 IDUP_Start_Protect()) are logically concatenated to form the 158 P-IDU, which is now ready to be sent to the target. The sender 159 then calls IDUP_Abolish_Env() to flush all environment-specific 160 information. 162 The receiver first calls IDUP_Establish_Env() to establish a 163 security environment for unprotecting P-IDUs. Then, for the 164 received P-IDU the receiver calls IDUP_Start_Unprotect(), 165 IDUP_Unprotect() for each buffer of data, and IDUP_End_Unprotect() 166 to complete the P-IDU unprotection. The receiver then calls 167 IDUP_Abolish_Env() to flush all environment-specific information. 169 Adams Document Expiration: 30 Sept. 1995 3 170 It is important to note that absolutely no synchronization is implied 171 or expected between the data buffer size used by the sender as input 172 to the protection calls, the data buffer size used by the receiver as 173 input to the unprotection calls, and the block sizes required by the 174 underlying protection algorithms (integrity and confidentiality). 175 All these sizes are meant to be independent; furthermore, the data 176 buffer sizes used for the protection and unprotection calls are 177 purely a function of the local environment where the calls are made. 179 The IDUP-GSS-API design assumes and addresses several basic goals, 180 including the following. 182 Mechanism independence: The IDUP-GSS-API defines an interface to 183 cryptographically implemented security services at a generic level 184 which is independent of particular underlying mechanisms. For 185 example, IDUP-GSS-API-provided services can be implemented by 186 secret-key technologies or public-key approaches. 188 Protocol environment independence: The IDUP-GSS-API is independent 189 of the communications protocol suites which may be used to 190 transfer P-IDUs, permitting use in a broad range of protocol 191 environments. 193 Protocol association independence: The IDUP-GSS-API's security 194 environment construct is independent of communications protocol 195 association constructs, so that IDUP-GSS-API services can be 196 invoked by applications, wholly independent of protocol 197 associations. 199 Suitability for a range of implementation placements: IDUP-GSS-API 200 clients are not constrained to reside within any Trusted Computing 201 Base (TCB) perimeter defined on a system where the IDUP-GSS-API is 202 implemented; security services are specified in a manner suitable 203 for both intra-TCB and extra-TCB callers. 205 1.1. IDUP-GSS-API Constructs 207 This section describes the basic elements comprising the 208 IDUP-GSS-API. 210 1.1.1. Credentials 212 Credentials in IDUP-GSS-API are to be understood and used as 213 described in GSS-API [RFC-1508]. 215 1.1.2. Tokens 217 Tokens in IDUP-GSS-API are to be understood and used as described in 218 GSS-API [RFC-1508] with the exception that there are no context-level 219 tokens generated by IDUP-GSS-API. Only two tokens, prot_token and 220 receipt_token, are defined by IDUP-GSS-API. The first is meant to 221 be logically concatenated with an IDU prior to transfer to a target; 222 the latter can be sent independently of any other data transfer. 223 Adams Document Expiration: 30 Sept. 1995 4 225 1.1.3. Security Environment 227 The "security environment" in IDUP-GSS-API is entirely different from 228 the concept of security contexts used in GSS-API [RFC-1508]. Here, a 229 security environment exists within a calling application (that is, it 230 is purely local to the caller) for the purpose of protecting or 231 unprotecting one or more IDUs using a particular caller credential. 232 In GSS-API, on the other hand, a security context exists between 233 peers (the initiator and the target) for the purpose of protecting, 234 in real time, the data that is exchanged between them. Although they 235 are different concepts, the IDUP_handle in IDUP-GSS-API is similar to 236 the context_handle in GSS-API in that it is a convenient way of tying 237 together the entire process of protecting or unprotecting one or more 238 IDUs. As with the GSS-API security contexts, a caller can initiate 239 and maintain multiple environments using the same or different 240 credentials. 242 1.1.4. Mechanism Types 244 Mechanism types in IDUP-GSS-API are to be understood and used as 245 described in GSS-API [RFC-1508]. 247 1.1.5. Naming 249 Naming in IDUP-GSS-API is to be understood and used as described in 250 GSS-API [RFC-1508]. 252 1.1.6. Channel Bindings 254 The concept of channel bindings discussed in GSS-API [RFC-1508] is 255 not relevant to the IDUP-GSS-API. 257 1.2. IDUP-GSS-API Features and Issues 259 This section describes aspects of IDUP-GSS-API operations and of the 260 security services which the IDUP-GSS-API provides. It also provides 261 commentary on design issues. 263 1.2.1. Status Reporting 265 Status reporting in IDUP-GSS-API is to be understood and used as 266 described in GSS-API [RFC-1508], with the addition of the following 267 IDUP-GSS-API major status codes: 269 Adams Document Expiration: 30 Sept. 1995 5 271 Table 1: IDUP-GSS-API Major Status Codes 273 FATAL ERROR CODES 275 IDUP_S_BAD_TARG_INFO target information is invalid or 276 unsuitable for IDU protection. 278 IDUP_S_BAD_DIGEST_ALG requested digest algorithm unsupported 280 IDUP_S_BAD_CONF_ALG requested conf. algorithm unsupported 282 IDUP_S_BAD_ENC_IDU encrypted IDU is defective/invalid 284 IDUP_S_NO_ENV no environment recognized for env_handle 286 IDUP_S_UNKNOWN_OPER_ID requested operation id. is unsupported 288 INFORMATORY STATUS CODES 290 IDUP_S_RECEIPTS_UNAVAIL mechanism does not support receipts 292 1.2.2. Per-IDU Security Service Availability 294 Per-IDU security service availability in IDUP-GSS-API is to be 295 understood and used as described in GSS-API [RFC-1508], with the 296 exception that integrity or confidentiality or both can be applied to 297 any IDU. 299 1.2.3. Per-IDU Replay Detection and Sequencing 301 The concept of per-IDU replay detection and sequencing discussed 302 in GSS-API [RFC-1508] is not relevant to the IDUP-GSS-API. 304 1.2.4. Quality of Protection 306 The concept of QOP control in IDUP-GSS-API is to be understood 307 essentially as described in GSS-API [RFC-1508]. However, the actual 308 description and use of the QOP parameter follows that given in the 309 Internet Draft "draft-ietf-cat-spkmgss-02.txt". This QOP description 310 allows either mechanism-independent labels or particular algorithm 311 labels to be specified by calling applications for both 312 confidentiality and integrity. 314 Adams Document Expiration: 30 Sept. 1995 6 316 2. Interface Descriptions 318 This section describes the IDUP-GSS-API's service interface, dividing 319 the set of calls offered into four groups. Credential management 320 calls are related to the acquisition and release of credentials by 321 API callers. Environment-level calls are related to the management of 322 the security environment by an API caller. Per-IDU calls are related 323 to the protection or unprotection of individual IDUs in established 324 security environments. Support calls provide ancillary functions 325 useful to IDUP-GSS-API callers. Table 2 groups and summarizes the 326 calls in tabular fashion (an asterisk marks the calls which are 327 identical to the GSS-API specification). 329 Table 2: IDUP-GSS-API Calls 331 CREDENTIAL MANAGEMENT 333 * GSS_Acquire_cred acquire credentials for use 334 * GSS_Release_cred release credentials after use 335 * GSS_Inquire_cred display information about credentials 337 ENVIRONMENT-LEVEL CALLS 339 IDUP_Establish_Env estbablish IDUP environment (to protect 340 and unprotect IDUs) 341 IDUP_Abolish_Env abolish env. when no longer needed 342 IDUP_Inquire_Env indicate characteristics of env. 344 PER-IDU CALLS 346 IDUP_Start_Protect begin the protection process 347 IDUP_Protect protect IDU (perhaps 1 buffer at a time) 348 IDUP_End_Protect end the protection process; create a 349 "protect token" which contains info. 350 necessary for the legitimate receiver(s) 351 of the P-IDU to unprotect it 353 IDUP_Start_Unprotect begin the unprotect process 354 IDUP_Unprotect use the "protect token" to unprotect the 355 P-IDU (possibly one buffer at a time) 356 IDUP_End_Unprotect end the unprotect process; create a 357 receipt token if this was requested 358 and if underlying mechanism supports it 359 IDUP_Process_Receipt process the receipt_token 361 Adams Document Expiration: 30 Sept. 1995 7 363 SUPPORT CALLS 365 * GSS_Display_status translate status codes to printable form 366 * GSS_Indicate_mechs indicate mech_types supported on local 367 system 368 * GSS_Compare_name compare two names for equality 369 * GSS_Display_name translate name to printable form 370 * GSS_Import_name convert printable name to normalize form 371 * GSS_Release_name free storage of normalized-form name 372 * GSS_Release_buffer free storage of printable name 373 * GSS_Release_oid_set free storage of OID set object 374 * GSS_Import_name_object import name from object 375 * GSS_Export_name_object export name to object 376 IDUP_Parse_Token examine the input token to determine 377 mech_type and token_type 379 2.1. Credential management calls 381 2.1.1. Relationship to GSS-API 383 Credential management in IDUP-GSS-API is to be understood and used as 384 described in GSS-API [RFC-1508]. The calls GSS_Acquire_cred(), 385 GSS_Release_cred(), and GSS_Inquire_cred() are unchanged. 387 2.2. Environment-level calls 389 This group of calls is devoted to the establishment and management of 390 an environment for the purpose of IDU protection and unprotection. 391 Before protecting or unprotecting any IDU, an application must call 392 IDUP_Establish_Env() to initialize environment information and select 393 the underlying IDUP-GSS mechanism to be used. A series of protection 394 or unprotection calls are made to process each IDU, resulting in a 395 "prot_token" or a "receipt_token" (if supported) for each. Finally, 396 IDUP_Abolish_Env() is called to flush all environment information. 398 2.2.1. Relationship to GSS-API 400 The set of calls described in this section replaces the calls 401 GSS_Init_sec_context(), GSS_Accept_sec_context(), 402 GSS_Delete_sec_context(), GSS_Process_context_token(), and 403 GSS_Context_time() which are specified in [RFC-1508]. 405 Adams Document Expiration: 30 Sept. 1995 8 407 2.2.2. IDUP_Establish_Env call 409 Inputs: 411 o claimant_cred_handle CREDENTIAL HANDLE, -NULL specifies "use 412 default" 414 o mech_type OBJECT IDENTIFIER, -NULL parameter specifies "use 415 default" 417 o time_req INTEGER, 419 o req_flags INTEGER, 421 Outputs: 423 o major_status INTEGER, 425 o minor_status INTEGER, 427 o env_handle ENVIRONMENT HANDLE, 429 o mech_type OBJECT IDENTIFIER, -actual mechanism always 430 indicated, never NULL 432 o time_rec INTEGER, 434 o ret_flags INTEGER, 436 Return major_status codes: 438 o GSS_S_COMPLETE indicates that environment-level information was 439 successfully initialized, and that IDU processing can begin on 440 the newly-established environment. 442 o GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks 443 performed on the credential structure referenced by 444 claimant_cred_handle failed, preventing further processing from 445 being performed using that credential structure. 447 o GSS_S_NO_CRED indicates that no environment was established, 448 either because the input cred_handle was invalid or because the 449 caller lacks authorization to access the referenced credentials. 451 o GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided 452 through the input claimant_cred_handle argument are no longer 453 valid, so environment establishment cannot be completed. 455 o GSS_S_BAD_MECH indicates that a mech_type unsupported by the 456 IDUP_GSS-API implementation type was requested, causing the 457 environment establishment operation to fail. 459 o GSS_S_FAILURE indicates that environment setup could not be 460 accomplished for reasons unspecified at the IDUP-GSS-API level, 461 and that no interface-defined recovery action is available. 463 Adams Document Expiration: 30 Sept. 1995 9 465 This routine is used by an application which protects or unprotects 466 IDUs. Using information in the credentials structure referenced by 467 claimant_cred_handle, IDUP_Establish_Env() initializes the data 468 structures required to protect or unprotect an IDU. The 469 claimant_cred_handle must correspond to a valid credentials 470 structure. 472 This routine returns an env_handle for all future references to 473 this environment; when protection, unprotection, or 474 IDUP_Abolish_Env() calls are made, this handle value will be used as 475 the input env_handle argument. 477 It is the caller's responsibility to establish a communications path 478 to the intended recipients of the P-IDU, and to transmit the P-IDU to 479 those recipients over that path. This may occur subsequent to the 480 IDUP_Abolish_Env() call. 482 The req_flags parameter may be used by the calling application to 483 request that integrity, confidentiality, and/or receipt processing be 484 available in the established environment. Requesting receipt 485 processing indicates that the calling application may wish to obtain 486 a proof of receipt (of an IDU which it will protect in the 487 established environment) from one or more of the intended recipients 488 of that P-IDU. 490 Not all features will be available in all underlying mech_types; the 491 returned value of ret_flags (receipts_avail, conf_avail, 492 integ_avail) indicates, as a function of mech_type processing 493 capabilities and the initiator-provided input flags, the set of 494 features which will be available in the environment. These state 495 indicators' values are undefined unless the routine's major_status 496 indicates COMPLETE. Failure to provide the precise set of features 497 desired by the caller does not cause environment establishment to 498 fail; it is the caller's prerogative to abolish the environment if 499 the feature set provided is unsuitable for the caller's use. The 500 returned mech_type value indicates the specific mechanism employed in 501 the environment, and will never indicate the value for "default". 503 The conf_avail return value (in the ret_flags paramter) indicates 504 whether the environment supports confidentiality services, and so 505 informs the caller whether or not a request for encryption through 506 the conf_req_flag input to IDUP_Protect() can be honored. In similar 507 fashion, the integ_avail return value indicates whether integrity 508 services are available in the established environment, and the 509 receipts_avail return value indicates whether receipt generation and 510 processing services are available. 512 Adams Document Expiration: 30 Sept. 1995 10 514 2.2.3. IDUP_Abolish_Env call 516 Input: 518 o env_handle ENVIRONMENT HANDLE 520 Outputs: 522 o major_status INTEGER, 524 o minor_status INTEGER, 526 Return major_status codes: 528 o GSS_S_COMPLETE indicates that the environment was recognized and 529 that relevant environment-specific information was flushed. 531 o IDUP_S_NO_ENV indicates that no valid environment was recognized 532 for the env_handle provided, so no deletion was performed. 534 o GSS_S_FAILURE indicates that the environment is recognized, but 535 that the requested operation could not be performed for reasons 536 unspecified at the IDUP-GSS-API level. 538 This call is made to flush environment-specific information. (Once an 539 environment is established, cached credential and environment-related 540 information is expected to be retained until an IDUP_Abolish_Env() 541 call is made or until the environment lifetime expires.) Attempts to 542 perform IDU processing on a deleted or expired environment will 543 result in error returns. 545 2.2.4: IDUP_Inquire_Env call 547 Input: 549 o env_handle ENVIRONMENT HANDLE, 551 Outputs: 553 o major_status INTEGER, 555 o minor_status INTEGER, 557 o mech_type OBJECT IDENTIFIER, -- the mechanism supporting this env. 559 o ret_flags INTEGER, 561 o time_rec INTEGER -- in seconds 563 Return major_status codes: 565 o GSS_S_COMPLETE indicates that the referenced environment is valid 566 and that mech_type, ret_flags, and time_rec return values describe 567 the corresponding characteristics of the environment. 569 Adams Document Expiration: 30 Sept. 1995 11 571 o IDUP_S_ENV_EXPIRED indicates that the provided input env_handle 572 is recognized, but that the referenced environment has expired. 573 Return values other than major_status and minor_status are 574 undefined. 576 o IDUP_S_NO_ENV indicates that no valid environment was recognized 577 for the env_handle provided, so no return values can be provided. 579 o GSS_S_FAILURE indicates that the environment is recognized, but 580 that the requested operation could not be performed for reasons 581 unspecified at the IDUP-GSS-API level. 583 This call is used to extract information describing characteristics 584 of the security environment. 586 2.3. Per-IDU calls 588 This group of calls is used to perform IDU protection processing 589 on an established IDUP environment. Some of these calls may block 590 pending network interactions (depending on the underlying mechanism 591 in use). These calls may be invoked by an IDU's protector or by the 592 P-IDU's recipient. The two sets of members of this group form a 593 pair; the output from the protection set is properly input to the 594 unprotection set. 596 The per-IDU calls support caller-requested confidentiality in 597 addition to data origin authentication / data integrity / non- 598 repudiation services. IDUP_End_Protect() outputs a token which 599 encapsulates all the information required to unprotect the IDU. The 600 token from IDUP_End_Protect() is passed to the target along with the 601 IDU and is processed by the unprotection calls at that system. 602 Unprotection performs decipherment or validation of P-IDUs (or both), 603 as required. 605 Note that each of the two main operations (protection and 606 unprotection) is separated into three parts: "Start_Operation"; 607 "Operation", called once for each buffer of input data; and 608 "End_Operation". This separation is done for convenience since the 609 parts require different parameters. "Start_Operation" allows the 610 caller to specify or retrieve the algorithms (through the QOP value) 611 used during the processing. "Operation" is concerned with the 612 processing itself, receiving a buffer of input data and, if 613 confidentiality is involved, returning a buffer of output data. 614 Finally, "End_Operation" performs any required clean-up and creates 615 the appropriate token or states whether the input token and IDU were 616 valid. 618 2.3.1. Relationship to GSS-API 620 The set of calls described in this section replaces the calls 621 GSS_Sign(), GSS_Verify(), GSS_Seal(), and GSS_Unseal() -- now named 622 GSS_GetMIC(), GSS_VerifyMIC, GSS_Wrap(), and GSS_Unwrap() -- which 623 are specified in [RFC-1508]. 625 Adams Document Expiration: 30 Sept. 1995 12 627 2.3.2. IDUP_Start_Protect call 629 Inputs: 631 o env_handle ENVIRONMENT HANDLE, 633 o digest_req_flag BOOLEAN, 635 o conf_req_flag BOOLEAN, 637 o qop_req INTEGER, -0 specifies default QOP 639 o targ_names SEQUENCE OF INTERNAL NAME, 641 o receipt_req_flag BOOLEAN, 643 o receipts_from SEQUENCE OF INTERNAL NAME, 644 -must be a subset of targ_names 646 o receipts_to SEQUENCE OF INTERNAL NAME, 648 o prot_oper_id INTEGER 649 -stage of protection operation to be performed 651 Outputs: 653 o major_status INTEGER, 655 o minor_status INTEGER, 657 o digest_state BOOLEAN, 659 o conf_state BOOLEAN, 661 o bad_targ_names SEQUENCE OF INTERNAL NAME, 663 Return major_status codes: 665 o GSS_S_COMPLETE indicates that the protection process can begin. 667 o GSS_S_CREDENTIALS_EXPIRED indicates that the environment is 668 recognized, but that its associated credentials have expired, so 669 that the requested operation cannot be performed. 671 o IDUP_S_ENV_EXPIRED indicates that the provided input env_handle 672 is recognized, but that the referenced environment has expired. 673 Return values other than major_status and minor_status are 674 undefined. 676 o IDUP_S_NO_ENV indicates that no valid environment was recognized 677 for the env_handle provided. 679 o IDUP_S_BAD_DIGEST_ALG indicates that the digest algorithm 680 specified is unavailable in the requested mechanism, so processing 681 cannot continue. 683 Adams Document Expiration: 30 Sept. 1995 13 685 o IDUP_S_UNKNOWN_OPER_ID indicates that the input prot_oper_id value 686 is not recognized or supported in the underlying mechanism. 688 o GSS_S_BAD_QOP indicates that the provided QOP value is not 689 recognized or supported for the environment. 691 o IDUP_S_BAD_CONF_ALG indicates that the confidentiality algorithm 692 specified is unavailable in the requested mechanism, so processing 693 cannot continue. 695 o IDUP_S_BAD_TARG_INFO indicates that the information regarding the 696 target(s) is invalid or is insufficient for the protection of an 697 IDU, so prot_token cannot be created. 699 o IDUP_S_RECEIPTS_UNAVAIL indicates that the underlying mechanism 700 does not support the generation of receipts by the unprotection 701 set of calls. 703 o GSS_S_FAILURE indicates that the environment is recognized, but 704 that the requested operation could not be performed for reasons 705 unspecified at the IDUP-GSS-API level. 707 Using the security environment referenced by env_handle, initialize 708 the data structures required to begin the process of protecting the 709 IDU buffers. If the digest_req_flag is TRUE, the caller requests 710 that data origin authentication and/or data integrity services be 711 applied to the IDU buffers. If the conf_req_flag is TRUE, the 712 caller requests that confidentiality be applied to the IDU 713 buffers. Confidentiality and authentication/integrity may not be 714 supported in all mech_types or by all implementations; the returned 715 conf_state and digest_state flags indicate whether confidentiality or 716 authentication/integrity, or both, can be provided for the IDU. 718 The qop_req parameter allows quality-of-protection control. Choice 719 of the digest algorithm determines whether non-repudiation services 720 can be supported for an IDU. 722 For those mechanisms which allow or require multiple stages of 723 processing, each producing a different aspect of protection for the 724 IDU, the operation identifier prot_oper_id is used to specify 725 which stage is currently being requested by the application. An 726 example where this would be useful is a mechanism which implements 727 the signed Message Security Protocol [MSP] -- see Section 3.2 for 728 details. 730 If one or more of the targets in targ_names cannot be used as a valid 731 recipient of the P-IDU, these names will be returned in 732 bad_targ_names. As long as at least one of the targets can be used, 733 this does not cause environment establishment to fail; it is the 734 caller's prerogative to abolish the environment if the target set 735 which can be used is unsuitable for the caller's purposes. 737 Adams Document Expiration: 30 Sept. 1995 14 739 2.3.3. IDUP_Protect call 741 Inputs: 743 o env_handle ENVIRONMENT HANDLE, 745 o input_buffer OCTET STRING 747 Outputs: 749 o major_status INTEGER, 751 o minor_status INTEGER, 753 o output_buffer OCTET STRING 755 Return major_status codes: 757 o GSS_S_COMPLETE indicates that the input_buffer has successfully 758 been included in the protection computation. 760 o GSS_S_CREDENTIALS_EXPIRED indicates that the environment is 761 recognized, but that its associated credentials have expired, so 762 that the requested operation cannot be performed. 764 o IDUP_S_NO_ENV indicates that no valid environment was recognized 765 for the env_handle provided. 767 o GSS_S_FAILURE indicates that the environment is recognized, but 768 that the required operation could not be performed for reasons 769 unspecified at the IDUP-GSS-API level. 771 Using the security environment referenced by env_handle, continue the 772 protection processing on the data in input_buffer and, if 773 confidentially was requested in IDUP_Start_Protect(), put the result 774 in output_buffer. 776 2.3.4. IDUP_End_Protect call 778 Inputs: 780 o env_handle ENVIRONMENT HANDLE, 782 Outputs: 784 o major_status INTEGER, 786 o minor_status INTEGER, 788 o output_buffer OCTET STRING 790 o prot_token OCTET STRING 792 Adams Document Expiration: 30 Sept. 1995 15 794 Return major_status codes: 796 o GSS_S_COMPLETE indicates that the protection computation has been 797 successfully completed and the result has been placed in 798 prot_token. If confidentiality was requested in 799 IDUP_Start_Protect(), output_buffer will contain any residual 800 ciphertext. 802 o GSS_S_CREDENTIALS_EXPIRED indicates that the environment is 803 recognized, but that its associated credentials have expired, so 804 that the requested operation cannot be performed. 806 o IDUP_S_NO_ENV indicates that no valid environment was recognized 807 for the env_handle provided. 809 o GSS_S_FAILURE indicates that the environment is recognized, but 810 that the requested operation could not be performed for reasons 811 unspecified at the IDUP-GSS-API level. 813 Using the security environment referenced by env_handle, complete the 814 protection processing on the data and place the computed protection 815 token in prot_token. 817 Successful application of IDUP_End_Protect() does not guarantee that 818 the corresponding unprotection set of calls can necessarily be 819 performed successfully when the P-IDU arrives at the target. 821 2.3.5. IDUP_Start_Unprotect call 823 Inputs: 825 o env_handle ENVIRONMENT HANDLE, 827 o prot_token OCTET STRING 829 o prot_oper_id INTEGER 830 -stage of unprotection operation to be performed 832 Outputs: 834 o major_status INTEGER, 836 o minor_status INTEGER, 838 o conf_state BOOLEAN -TRUE implies that conf. was applied 840 o digest_state BOOLEAN -TRUE implies that integrity was applied 842 o qop_state INTEGER, 844 o originator_info OCTET STRING 846 Adams Document Expiration: 30 Sept. 1995 16 848 Return major_status codes: 850 o GSS_S_COMPLETE indicates that unprotection processing can begin. 852 o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed 853 on the received prot_token failed, preventing further processing 854 from being performed with that token. 856 o GSS_S_CREDENTIALS_EXPIRED indicates that the environment is 857 recognized, but that its associated credentials have expired, so 858 that the requested operation cannot be performed. 860 o IDUP_S_ENV_EXPIRED indicates that the provided input env_handle 861 is recognized, but that the referenced environment has expired. 862 Return values other than major_status and minor_status are 863 undefined. 865 o IDUP_S_NO_ENV indicates that no valid environment was recognized 866 for the env_handle provided. 868 o IDUP_S_UNKNOWN_OPER_ID indicates that the input prot_oper_id value 869 is not recognized or supported in the underlying mechanism. 871 o IDUP_S_BAD_DIGEST_ALG indicates that the digest algorithm 872 specified in prot_token is unavailable in the local mechanism, so 873 processing cannot continue. 875 o IDUP_S_BAD_CONF_ALG indicates that the confidentiality algorithm 876 specified in prot_token is unavailable in the local mechanism, so 877 processing cannot continue. 879 o GSS_S_FAILURE indicates that the environment is recognized, but 880 that the requested operation could not be performed for reasons 881 unspecified at the IDUP-GSS-API level. 883 Using the security environment referenced by env_handle, initialize 884 the data structures required to begin the process of unprotecting a 885 P-IDU. If the returned conf_state value is TRUE, then 886 confidentiality was applied to the IDU and the confidentiality 887 portion of qop_state specifies the algorithm which was used. 888 Similarly, if the returned digest_state value is TRUE, then data 889 integrity / data origin authentication services were applied to the 890 IDU and the integrity portion of qop_state specifies the algorithm 891 which was used. 893 If underlying mechanism supports it and if this information is 894 contained in prot_token, return information regarding the originator 895 (that is, the entity which used the protection set of calls to 896 protect this IDU) in originator_info. 898 Adams Document Expiration: 30 Sept. 1995 17 900 2.3.6. IDUP_Unprotect call 902 Inputs: 904 o env_handle ENVIRONMENT HANDLE, 906 o input_buffer OCTET STRING 908 Outputs: 910 o major_status INTEGER, 912 o minor_status INTEGER, 914 o output_buffer OCTET STRING 916 Return major_status codes: 918 o GSS_S_COMPLETE indicates that the input_buffer has successfully 919 been included in the unprotection computation. 921 o GSS_S_CREDENTIALS_EXPIRED indicates that the environment is 922 recognized, but that its associated credentials have expired, so 923 that the requested operation cannot be performed. 925 o IDUP_S_NO_ENV indicates that no valid environment was recognized 926 for the env_handle provided. 928 o GSS_S_FAILURE indicates that the environment is recognized, but 929 that the requested operation could not be performed for reasons 930 unspecified at the IDUP-GSS-API level. 932 Using the security environment referenced by env_handle, continue the 933 unprotect processing on the data in input_buffer. If confidentiality 934 was applied to the IDU, put the decrypted data in output_buffer. 936 2.3.7. IDUP_End_Unprotect call 938 Inputs: 940 o env_handle ENVIRONMNENT HANDLE, 942 Outputs: 944 o major_status INTEGER, 946 o minor_status INTEGER, 948 o output_buffer OCTET STRING 950 o receipt_token OCTET STRING 952 Adams Document Expiration: 30 Sept. 1995 18 953 Return major_status codes: 955 o GSS_S_COMPLETE indicates that the unprotect computation was 956 successful. If confidentiality was applied to the IDU, 957 output_buffer will contain any residual plaintext. 959 o GSS_S_BAD_SIG indicates that the received prot_token contains an 960 incorrect digest for the data. 962 o IDUP_S_BAD_ENC_IDU indicates that decryption of the received IDU 963 cannot be completed because the encrypted IDU was 964 invalid/defective (for example the final block was short or had 965 incorrect padding). 967 o GSS_S_CREDENTIALS_EXPIRED indicates that the environment is 968 recognized, but that its associated credentials have expired, so 969 that the requested operation cannot be performed. 971 o IDUP_S_NO_ENV indicates that no valid environment was recognized 972 for the env_handle provided. 974 o GSS_S_FAILURE indicates that the environment is recognized, but 975 that the requested operation could not be performed for reasons 976 unspecified at the IDUP-GSS-API level. 978 Using the security environment referenced by env_handle, complete the 979 unprotect processing on the data and return the appropriate status 980 code. If a receipt was requested by the sender of the P-IDU (and the 981 underlying mechanism supports this), receipt_token will contain this 982 receipt in a form suitable for transfer back to the sender. 984 Note that, unlike GSS-API, IDUP-GSS-API does not incorporate the 985 concept of error tokens since the protection and unprotection of an 986 IDU may be separated by an indefinite amount of time and may or may 987 not be performed by the same entity. 989 2.3.8. IDUP_Process_Receipt call 991 Inputs: 993 o env_handle ENVIRONMENT HANDLE, 995 o receipt_token OCTET STRING 997 Outputs: 999 o major_status INTEGER, 1001 o minor_status INTEGER, 1003 o originator_info OCTET STRING 1005 Return major_status codes: 1007 o GSS_S_COMPLETE indicates that receipt processing was successful. 1008 Adams Document Expiration: 30 Sept. 1995 19 1010 o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed 1011 on the received receipt_token failed, preventing further 1012 processing from being performed with that token. 1014 o IDUP_S_ENV_EXPIRED indicates that the provided input env_handle 1015 is recognized, but that the referenced environment has expired. 1016 Return values other than major_status and minor_status are 1017 undefined. 1019 o IDUP_S_RECEIPTS_UNAVAIL indicates that the underlying mechanism 1020 does not support the generation or processing of receipts. 1022 o IDUP_S_NO_ENV indicates that no valid environment was recognized 1023 for the env_handle provided. 1025 o GSS_S_FAILURE indicates that the environment is recognized, but 1026 that the requested operation could not be performed for reasons 1027 unspecified at the IDUP-GSS-API level. 1029 Using the security environment referenced by env_handle, initialize 1030 the data structures required to process the received receipt_token 1031 and return the appropriate status value. Information regarding the 1032 creator of the receipt_token may be returned in originator_info, if 1033 the underlying mechanism supports it. 1035 2.4. Support calls 1037 2.4.1. Relationship to GSS-API 1039 Support calls in IDUP-GSS-API are to be understood and used as 1040 described in GSS-API [RFC-1508]. The calls GSS_Display_status(), 1041 GSS_Indicate_mechs(), GSS_Compare_name(), GSS_Display_name(), 1042 GSS_Import_name(), GSS_Release_name(), GSS_Release_buffer(), 1043 GSS_Release_oid_set(), GSS_Import_name_object(), and 1044 GSS_Export_name_object() are unchanged. 1046 2.4.2. IDUP_Parse_token call 1048 Inputs: 1050 o input_token OCTET STRING 1052 Outputs: 1054 o major_status INTEGER, 1056 o minor_status INTEGER, 1058 o mech_type OBJECT IDENTIFIER, 1060 o token_type INTEGER, 1062 Adams Document Expiration: 30 Sept. 1995 20 1064 Return major_status codes: 1066 o GSS_S_COMPLETE indicates that the input_token could be parsed for 1067 both fields. The resulting values are stored in mech_type and 1068 token_type. 1070 o GSS_S_DEFECTIVE_TOKEN indicates that the mechanism type could be 1071 parsed, but that either the token type could not be determined 1072 from the input token, or the value determined did not correspond 1073 to any valid token_type. 1075 o GSS_S_FAILURE indicates that the mechanism type could not be 1076 parsed (for example, the token may be corrupted). 1078 IDUP_Parse_Token() is used to return to an application the mechanism 1079 type and token type which correspond to a given input token. Since 1080 IDUP-GSS-API tokens are meant to be opaque to the calling 1081 application, this function allows the application to determine 1082 information about the token without having to violate the opaqueness 1083 intention of IDUP. Of primary importance is the mechanism type, 1084 which the application can then use as input to the 1085 IDUP_Establish_Env() call in order to establish the correct 1086 environment in which to have the token processed. The token_type may 1087 be used to allow the application to determine whether to pass the 1088 token to the IDUP_Start_Unprotect() call or the 1089 IDUP_Process_Receipt() call. 1091 If all tokens are framed as suggested in RFC-1508, Appendix B 1092 (specified in the Kerberos V5 GSS mechanism [KRB5], in the SPKM GSS 1093 Mechanism [SPKM], and in this document), then any mechanism 1094 implementation should be able to return at least the mech_type 1095 parameter (the token_type parameter being NULL) for any uncorrupted 1096 input token. If the mechanism implementation whose 1097 IDUP_Parse_token() function is being called does recognize the token, 1098 it can return token_type so that the application can subsequently 1099 call IDUP_Start_Unprotect() or IDUP_Process_Receipt(). 1101 Note that no minor status return codes have been defined for this 1102 function at this time. 1104 2.4.2.1. The token_type Output Parameter 1106 The following token types are defined: 1108 IDUP_PROT_TOKEN = 1 1109 IDUP_RECEIPT_TOKEN = 2 1111 Every mechanism must be able to perform the mapping from an input 1112 token to one of the above token types (for any token generated by 1113 that mechanism). 1115 Adams Document Expiration: 30 Sept. 1995 21 1116 3. Mechanism-Specific Example Scenarios 1118 This section provides an illustrative overview of the use of a 1119 candidate mechanism type to support the IDUP-GSS-API. This discussion 1120 is intended primarily for readers familiar with the specific security 1121 technology, demonstrating how IDUP-GSS-API functions can be used and 1122 implemented by a candidate underlying mechanism. It should not be 1123 regarded as constrictive to implementations or as defining the only 1124 means through which IDUP-GSS-API functions can be realized with a 1125 particular underlying technology, and does not demonstrate all 1126 IDUP-GSS-API features. 1128 3.1. PEM-compliant file protection 1130 A PEM-compliant IDUP-GSS-API mechanism would have as its prot_token 1131 a PEM-compliant header for a protected (encrypted and/or signed) file 1132 [RFC-1421]. A calling application wishing to encrypt and sign a data 1133 file would initiate an environment using IDUP_Establish_Env(), 1134 passing in the appropriate mech_type and a FALSE receipt_req. 1135 IDUP_Start_Protect() is called next to specify that both encryption 1136 and authentication/integrity are desired, and a QOP value is input 1137 specifying either particular algorithms to be used (if the 1138 application is aware of algorithms supported by the underlying 1139 mechanism) or "generic" values. As well, the targ_names (possibly a 1140 set of Distinguished Names) are specified at this time to be used in 1141 the construction of prot_token. Any targets which cannot be used as 1142 valid recipients (for example, because they do not have public-key 1143 certificates which can be accessed by the mechanism) are returned in 1144 bad_targ_names. 1146 The file is then encrypted and signed one buffer at a time using 1147 IDUP_Protect(). As each IDUP_Protect() call returns, the application 1148 writes output_buffer (which contains ciphertext) to the end of an 1149 output file. After the last input_buffer has been protected, the 1150 application calls IDUP_End_Protect(). Any residual ciphertext is 1151 returned in output_buffer, which is then written to the end of the 1152 output file. As well, the returned prot_token is prepended to the 1153 beginning of the output file. The output file is the "P-IDU" which 1154 can be transferred by any means to the intended recipient(s). 1156 Assuming that this is the only IDU to be protected at this time, 1157 the application abolishes the environment by calling 1158 IDUP_Abolish_Env(). 1160 The recipient of the P-IDU begins by calling IDUP_Parse_Token() 1161 to determine the mech_type of the received token (the token_type 1162 is redundant information for a PEM-compliant IDUP-GSS-API mechanism, 1163 since receipts are not defined for such a mechanism). 1164 IDUP_Establish_Env() is then called to initialize the environment. 1166 The recipient then calls IDUP_Start_Unprotect(), passing it the 1167 prot_token, IDUP_Unprotect() (once for each buffer of data), 1168 and IDUP_End_Unprotect(). Output buffers are written to an output 1169 file; after IDUP_End_Unprotect() has been called this file is the 1170 original IDU which the sender protected. 1172 The recipient then abolishes the env. by calling IDUP_Abolish_Env(). 1173 Adams Document Expiration: 30 Sept. 1995 22 1175 3.2. Signed-MSP-compliant file protection 1177 An MSP-compliant IDUP-GSS-API mechanism would be virtually identical 1178 to the PEM-compliant mechanism described above (for details regarding 1179 MSP see [MSP]). A Signed-MSP-compliant mechanism, however, requires 1180 a signature on the MSP IDU itself -- that is, on the MSP header and 1181 the encapsulated (possibly encrypted) content. This can be achieved 1182 using the prot_oper_id parameter of the IDUP_Start_Protect() call. 1183 For example, if prot_oper_id = 1 then the protection set of calls 1184 would produce a prot_token which is the MSP header and which is then 1185 concatenated with the (possibly encrypted) IDU to create an MSP IDU. 1186 If the protection set were then called again on MSP IDU with 1187 prot_oper_id = 2, prot_token would be the signature on MSP IDU, which 1188 would be appended to MSP IDU to create the Signed-MSP IDU (i.e., the 1189 final P-IDU). 1191 MSP recognizes at least two kinds of recipients, intermediate Message 1192 Transfer Agents (MTAs) and end User Agents (UAs). An MTA may be able 1193 to validate that a Signed-MSP IDU is valid, but only end UAs should 1194 be able to retrieve MSP-protected data. Thus, the MTA would call the 1195 unprotection set of calls with prot_oper_id = 2 to verify the 1196 signature on the MSP IDU, but would be unable to successfully call 1197 the unprotection set with prot_oper_id = 1 since it would lack the 1198 proper credentials. A valid end UA (one of the specified targets of 1199 the P-IDU), on the other hand, would be able to unprotect the Signed- 1200 MSP IDU with either value of prot_oper_id. 1202 Note that a receipt generated by an MSP-compliant mechanism will be 1203 sent to the IDU protector as a receipt_token and will be processed 1204 using the IDUP_Process_Receipt() call. 1206 4. Related Activities 1208 In order to implement the IDUP-GSS-API atop existing, emerging, and 1209 future security mechanisms, 1211 object identifiers must be assigned to candidate IDUP-GSS-API 1212 mechanisms and the name types which they support, and 1214 concrete data element formats must be defined for candidate 1215 mechanisms. 1217 Calling applications must implement formatting conventions which will 1218 enable them to distinguish IDUP-GSS-API P-IDUs from other 1219 IDUs in their environment. 1221 Concrete language bindings are required for the programming 1222 environments in which the IDUP-GSS-API is to be employed; such 1223 bindings for the C language are available in an associated draft. 1225 Adams Document Expiration: 30 Sept. 1995 23 1227 5. Acknowledgments 1229 Many thanks are due to Warwick Ford and Paul Van Oorschot of 1230 Bell-Northern Research for a number of helpful comments. 1232 6. Security Considerations 1234 Security issues are discussed throughout this memo. 1236 7. REFERENCES 1238 [MSP]: U.S. National Security Agency, "Message Security 1239 Protocol", Secure Data Network System SDN.701, March 1994. 1241 [RFC-1421]: J. Linn, "Privacy Enhancement for Internet Electronic 1242 Mail: Part I: Message Encryption and Authentication Procedures", 1243 RFC 1421. 1245 [RFC-1508]: J. Linn, "Generic Security Service Application Program 1246 Interface", RFC 1508. 1248 8. Author's Address 1250 Carlisle Adams 1251 Bell-Northern Research 1252 P.O.Box 3511, Station C 1253 Ottawa, Ontario, CANADA K1Y 4H7 1255 Phone: +1 613.763.9008 1256 E-mail: cadams@bnr.ca 1258 Adams Document Expiration: 30 Sept. 1995 24 1260 APPENDIX A 1262 MECHANISM-INDEPENDENT TOKEN FORMAT 1264 This appendix specifies a mechanism-independent level of 1265 encapsulating representation for IDUP-GSS-API tokens, incorporating 1266 an identifier of the mechanism type to be used when processing those 1267 tokens. Use of this format (with ASN.1-encoded data elements 1268 represented in BER, constrained in the interests of parsing 1269 simplicity to the Distinguished Encoding Rule (DER) BER subset 1270 defined in X.509, clause 8.7) is recommended to the designers of 1271 IDUP-GSS-API implementations based on various mechanisms, so that 1272 tokens can be interpreted unambiguously at IDUP-GSS-API peers. There 1273 is no requirement that the mechanism-specific protToken data element 1274 be encoded in ASN.1 BER. 1276 -- top-level token definition to frame different mechanisms 1278 IDUP-GSS-API DEFINITIONS ::= 1279 BEGIN 1280 MechType ::= OBJECT IDENTIFIER 1282 ProtToken ::= 1283 -- option indication done within mechanism-specific token 1285 [APPLICATION 0] IMPLICIT SEQUENCE { 1286 thisMech MechType, 1287 protToken ANY DEFINED BY thisMech 1288 -- contents mechanism-specific 1289 } 1291 ReceiptToken ::= 1293 [APPLICATION 0] IMPLICIT SEQUENCE { 1294 thisMech MechType, 1295 receiptToken ANY DEFINED BY thisMech 1296 -- contents mechanism-specific 1297 } 1298 END 1300 APPENDIX B 1302 MECHANISM DESIGN CONSTRAINTS 1304 The following constraints on IDUP-GSS-API mechanism designs are 1305 adopted in response to observed caller protocol requirements, and 1306 adherence thereto is anticipated in subsequent descriptions of 1307 IDUP-GSS-API mechanisms to be documented in standards-track Internet 1308 specifications. 1310 Use of the approach defined in Appendix A of this specification, 1311 applying a mechanism type tag to the ProtToken and the ReceiptToken 1312 (if defined), is required. 1314 Adams Document Expiration: 30 Sept. 1995 25