idnits 2.17.1 draft-ietf-cat-genericsec-02.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-19) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 6 months document validity. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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 an Authors' Addresses Section. ** There are 485 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 860 has weird spacing: '...t_token pro...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 1992) is 11570 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 section? '1' on line 80 looks like a reference -- Missing reference section? '3' on line 413 looks like a reference -- Missing reference section? '4' on line 488 looks like a reference -- Missing reference section? '6' on line 779 looks like a reference -- Missing reference section? '7' on line 1042 looks like a reference -- Missing reference section? '8' on line 1047 looks like a reference -- Missing reference section? '9' on line 2399 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 2626 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Generic Security Service API: Internet-Draft: August 1992 3 Common Authentication Technology WG: John Linn (DEC) 5 John Linn 6 Networking and Communications Architecture 7 Digital Equipment Corporation 8 550 King Street, LKG1-2/A19 9 Littleton, MA 01460 10 Linn@erlang.enet.dec.com 12 STATUS OF THIS MEMO 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 Areas, and its Working Groups. Note that other groups may also 17 distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted 21 by other documents at any time. It is not appropriate to use 22 Internet Drafts as reference material or to cite them other than 23 as a "working draft" or "work in progress." 25 Please check the I-D abstract listing contained in each Internet 26 Draft directory to learn the current status of this or any other 27 Internet Draft. 29 1 GSS-API Characteristics and Concepts 31 This Generic Security Service Application Program Interface 32 (GSS-API) definition provides security services to callers 33 in a generic fashion, supportable with a range of underlying 34 mechanisms and technologies and hence allowing source-level 35 portability of applications to different environments. This 36 specification defines GSS-API services and primitives at a level 37 independent of underlying mechanism and programming language 38 environment, and is to be complemented by other, related speci- 39 fications: 41 o documents defining specific parameter bindings for particular 42 language environments 44 Document Expiration: 28 February 1993 1 45 Generic Security Service API: Internet-Draft: August 1992 46 Common Authentication Technology WG: John Linn (DEC) 48 o documents defining token formats, protocols, and procedures 49 to be implemented in order to realize GSS-API services atop 50 particular security mechanisms 52 The operational paradigm in which GSS-API operates (also sum- 53 marized in Figure 1 in the graphic version of this document) 54 is as follows. A typical GSS-API caller is itself a communi- 55 cations protocol, calling on GSS-API in order to protect its 56 communications with authentication, integrity, and/or confi- 57 dentiality security services. A GSS-API caller accepts tokens 58 provided to it by its local GSS-API implementation and trans- 59 fers the tokens to a peer on a remote system; that peer passes 60 the received tokens to its local GSS-API implementation for 61 processing. The security services available through GSS-API 62 in this fashion are implementable (and have been implemented) 63 over a range of underlying mechanisms based on secret-key and 64 public-key cryptographic technologies. 66 The GSS-API separates the operations of initializing a security 67 context between peers, achieving peer entity authentication[1] 68 (GSS_Init_sec_context() and GSS_Accept_sec_context() calls), 69 from the operations of providing per-message data origin au- 70 thentication and data integrity protection (GSS_Sign() and GSS_ 71 Verify() calls) for messages subsequently transferred in con- 72 junction with that context. Per-message GSS_Seal() and GSS_ 73 Unseal() calls provide the data origin authentication and data 74 integrity services which GSS_Sign() and GSS_Verify() offer, and 75 also support selection of confidentiality services as a caller 76 option. Additional calls provide supportive functions to the 77 GSS-API's users. 79 ___________________ 80 [1] This security service definition, and other definitions used 81 in this document, corresponds to that provided in Interna- 83 tional Standard ISO 7498-2-1988(E), Security Architecture. 85 2 Document Expiration: 28 February 1993 86 Generic Security Service API: Internet-Draft: August 1992 87 Common Authentication Technology WG: John Linn (DEC) 89 In the graphic version of this document, Figure 2 illustrates 90 the dataflows involved in use of the GSS-API by a client and 91 server in a mechanism-independent fashion, establishing a secu- 92 rity context and transferring a protected message. The example 93 assumes that credential acquisition has already been completed. 94 Only a subset of parameter and result values are illustrated, 95 for reasons of clarity in exposition. Further, it is assumed 96 that the underlying authentication technology is capable of au- 97 thenticating a client to a server using elements carried within 98 a single token, and of authenticating the server to the client 99 (mutual authentication) with a single returned token; this as- 100 sumption holds for presently-documented CAT mechanisms but is 101 not necessarily true for other cryptographic technologies and 102 associated protocols. 104 The client calls GSS_Init_sec_context() to establish a security 105 context to the server identified by targ_name, and elects to 106 set the mutual_req_flag so that mutual authentication is per- 107 formed in the course of context establishment. GSS_Init_sec_ 108 context() returns an output_token to be passed to the server, 109 and indicates GSS_CONTINUE_NEEDED status pending completion of 110 the mutual authentication sequence. Had mutual_req_flag not been 111 set, the initial call to GSS_Init_sec_context() would have re- 112 turned GSS_COMPLETE status. The client sends the output_token to 113 the server. 115 The server passes the received token as the input_token pa- 116 rameter to GSS_Accept_sec_context(). GSS_Accept_sec_context 117 indicates GSS_COMPLETE status, provides the client's authenti- 118 cated identity in the src_name result, and provides an output_ 119 token to be passed to the client. The server sends the output_ 120 token to the client. 122 Document Expiration: 28 February 1993 3 123 Generic Security Service API: Internet-Draft: August 1992 124 Common Authentication Technology WG: John Linn (DEC) 126 The client passes the received token as the input_token pa- 127 rameter to a successor call to GSS_Init_sec_context(), which 128 processes data included in the token in order to achieve mu- 129 tual authentication from the client's viewpoint. This call to 130 GSS_Init_sec_context() returns GSS_COMPLETE status, indicating 131 successful mutual authentication and the completion of context 132 establishment for this example. 134 The client generates a data message and passes it to GSS_ 135 Seal(). GSS_Seal() performs data origin authentication, data 136 integrity, and (optionally) confidentiality processing on the 137 message and encapsulates the result into output_message, indi- 138 cating GSS_COMPLETE status. The client sends the output_message 139 to the server. 141 The server passes the received message to GSS_Unseal(). GSS_ 142 Unseal inverts the encapsulation performed by GSS_Seal(), de- 143 ciphers the message if the optional confidentiality feature was 144 applied, and validates the data origin authentication and data 145 integrity checking quantities. GSS_Unseal() indicates success- 146 ful validation by returning GSS_COMPLETE status along with the 147 resultant output_message. 149 For purposes of this example, we assume that the server knows 150 by out-of-band means that this context will have no further 151 use after one protected message is transferred from client to 152 server. Given this premise, the server now calls GSS_Delete_sec_ 153 context() to flush context-level information. GSS_Delete_sec_ 154 context returns a context_token for the server to pass to the 155 client. 157 The client passes the returned context_token to GSS_Process_ 158 context_token(), which returns GSS_COMPLETE status after delet- 159 ing context-level information at the client system. 161 The GSS-API design assumes and addresses several basic goals, 162 including: 164 o Mechanism independence: The GSS-API defines an interface 165 to cryptographically implemented strong authentication and 167 4 Document Expiration: 28 February 1993 168 Generic Security Service API: Internet-Draft: August 1992 169 Common Authentication Technology WG: John Linn (DEC) 171 other security services at a generic level which is inde- 172 pendent of particular underlying mechanisms. For example, 173 GSS-API-provided services can be implemented by secret-key 174 technologies (e.g., Kerberos) or public-key approaches (e.g., 175 X.509). 177 o Protocol environment independence: The GSS-API is indepen- 178 dent of the communications protocol suites with which it is 179 employed, permitting use in a broad range of protocol en- 180 vironments. In appropriate environments, an intermediate 181 implementation "veneer" which is oriented to a particular 182 communication protocol (e.g., Remote Procedure Call (RPC)) 183 may be interposed between applications which call that proto- 184 col and the GSS-API, thereby invoking GSS-API facilities in 185 conjunction with that protocol's communications invocations. 187 o Protocol association independence: The GSS-API's security 188 context construct is independent of communications protocol 189 association constructs. This characteristic allows a single 190 GSS-API implementation to be utilized by a variety of in- 191 voking protocol modules on behalf of those modules' calling 192 applications. GSS-API services can also be invoked directly 193 by applications, wholly independent of protocol associations. 195 o Suitability to a range of implementation placements: GSS- 196 API clients are not constrained to reside within any Trusted 197 Computing Base (TCB) perimeter defined on a system where the 198 GSS-API is implemented; security services are specified in a 199 manner suitable to both intra-TCB and extra-TCB callers. 201 1.1 GSS-API Constructs 203 This section describes the basic elements comprising the GSS- 204 API. 206 Document Expiration: 28 February 1993 5 207 Generic Security Service API: Internet-Draft: August 1992 208 Common Authentication Technology WG: John Linn (DEC) 210 1.1.1 Credentials 212 Credentials structures provide the prerequisites enabling peers 213 to establish security contexts with each other. A caller may 214 designate that its default credential be used for context es- 215 tablishment calls without presenting an explicit handle to that 216 credential. Alternately, those GSS-API callers which need to 217 make explicit selection of particular credentials structures may 218 make references to those credentials through GSS-API-provided 219 credential handles ("cred_handles"). 221 A single credential structure may be used for initiation of 222 outbound contexts and acceptance of inbound contexts. Callers 223 needing to operate in only one of these modes may designate this 224 fact when credentials are acquired for use, allowing underlying 225 mechanisms to optimize their processing and storage require- 226 ments. The credential elements defined by a particular mechanism 227 may contain multiple cryptographic keys, e.g., to enable authen- 228 tication and message encryption to be performed with different 229 algorithms. 231 A single credential structure may accommodate credential in- 232 formation associated with multiple underlying mechanisms (mech_ 233 types); a credential structure's contents will vary depending 234 on the set of mech_types supported by a particular GSS-API im- 235 plementation. Commonly, a single mech_type will be used for all 236 security contexts established by a particular initiator to a 237 particular target; the primary motivation for supporting cre- 238 dential sets representing multiple mech_types is to allow ini- 239 tiators on systems which are equipped to handle multiple types 240 to initiate contexts to targets on other systems which can ac- 241 commodate only a subset of the set supported at the initiator's 242 system. 244 It is the responsibility of underlying system-specific mech- 245 anisms and OS functions below the GSS-API to ensure that the 246 ability to acquire and use credentials associated with a given 248 6 Document Expiration: 28 February 1993 249 Generic Security Service API: Internet-Draft: August 1992 250 Common Authentication Technology WG: John Linn (DEC) 252 identity is constrained to appropriate processes within a sys- 253 tem. This responsibility should be taken seriously by implemen- 254 tors, as the ability for an entity to utilize a principal's cre- 255 dentials is equivalent to the entity's ability to successfully 256 assert that principal's identity. 258 Once a set of GSS-API credentials is established, the transfer- 259 ability of that credentials set to other processes or analogous 260 constructs within a system is a local matter, not defined by the 261 GSS-API. An example local policy would be one in which any cre- 262 dentials received as a result of login to a given user account, 263 or of delegation of rights to that account, are accessible by, 264 or transferable to, processes running under that account. 266 The credential establishment process (particularly when per- 267 formed on behalf of users rather than server processes) is 268 likely to require access to passwords or other quantities which 269 should be protected locally and exposed for the shortest time 270 possible. As a result, it will often be appropriate for pre- 271 liminary credential establishment to be performed through local 272 means at user login time, with the result(s) cached for sub- 273 sequent reference. These preliminary credentials would be set 274 aside (in a system-specific fashion) for subsequent use, either: 276 o to be accessed by an invocation of the GSS-API GSS_Acquire_ 277 cred() call, returning an explicit handle to reference that 278 credential 280 o as the default credentials installed on behalf of a process 282 1.1.2 Tokens 284 Tokens are data elements transferred between GSS-API callers, 285 and are divided into two classes. Context-level tokens are ex- 286 changed in order to establish and manage a security context 287 between peers. Per-message tokens are exchanged in conjunction 288 with an established context to provide protective security ser- 289 vices for corresponding data messages. The internal contents of 290 both classes of tokens are specific to the particular underlying 292 Document Expiration: 28 February 1993 7 293 Generic Security Service API: Internet-Draft: August 1992 294 Common Authentication Technology WG: John Linn (DEC) 296 mechanism used to support the GSS-API; Appendix B of this docu- 297 ment provides a uniform recommendation for designers of GSS-API 298 support mechanisms, encapsulating mechanism-specific information 299 along with a globally-interpretable mechanism identifier. 301 Tokens are opaque from the viewpoint of GSS-API callers. They 302 are generated within the GSS-API implementation at an end sys- 303 tem, provided to a GSS-API caller to be transferred to the peer 304 GSS-API caller at a remote end system, and processed by the 305 GSS-API implementation at that remote end system. Tokens may 306 be output by GSS-API primitives (and are to be transferred to 307 GSS-API peers) independent of the status indications which those 308 primitives indicate. Token transfer may take place in an in-band 309 manner, integrated into the same protocol stream used by the 310 GSS-API callers for other data transfers, or in an out-of-band 311 manner across a logically separate channel. 313 Development of GSS-API support primitives based on a partic- 314 ular underlying cryptographic technique and protocol does not 315 necessarily imply that GSS-API callers invoking that GSS-API 316 mechanism type will be able to interoperate with peers invoking 317 the same technique and protocol outside the GSS-API paradigm. 318 For example, the format of GSS-API tokens defined in conjunc- 319 tion with a particular mechanism, and the techniques used to 320 integrate those tokens into callers' protocols, may not be the 321 same as those used by non-GSS-API callers of the same underlying 322 technique. 324 1.1.3 Security Contexts 326 Security contexts are established between peers, using cre- 327 dentials established locally in conjunction with each peer or 328 received by peers via delegation. Multiple contexts may ex- 329 ist simultaneously between a pair of peers, using the same or 330 different sets of credentials. Coexistence of multiple con- 331 texts using different credentials allows graceful rollover when 332 credentials expire. Distinction among multiple contexts based 334 8 Document Expiration: 28 February 1993 335 Generic Security Service API: Internet-Draft: August 1992 336 Common Authentication Technology WG: John Linn (DEC) 338 on the same credentials serves applications by distinguishing 339 different message streams in a security sense. 341 The GSS-API is independent of underlying protocols and address- 342 ing structure, and depends on its callers to transport GSS-API- 343 provided data elements. As a result of these factors, it is a 344 caller responsibility to parse communicated messages, separat- 345 ing GSS-API-related data elements from caller-provided data. 346 The GSS-API is independent of connection vs. connectionless 347 orientation of the underlying communications service. 349 No correlation between security context and communications 350 protocol association is dictated[ 2]. This separation allows 351 the GSS-API to be used in a wide range of communications en- 352 vironments, and also simplifies the calling sequences of the 353 individual calls. In many cases (depending on underlying secu- 354 rity protocol, associated mechanism, and availability of cached 355 information), the state information required for context setup 356 can be sent concurrently with initial signed user data, without 357 interposing additional message exchanges. 359 1.1.4 Mechanism Types 361 In order to successfully establish a security context with a 362 target peer, it is necessary to identify an appropriate underly- 363 ing mechanism type (mech_type) which both initiator and target 364 peers support. The definition of a mechanism embodies not only 365 the use of a particular cryptographic technology (or a hybrid or 366 choice among alternative cryptographic technologies), but also 367 definition of the syntax and semantics of data element exchanges 368 which that mechanism will employ in order to support security 369 services. 371 ___________________ 372 [ 2] The optional channel binding facility, discussed in Sec- 373 tion 1.1.6 of this document, represents an intentional excep- 374 tion to this rule, supporting additional protection features 376 within GSS-API supporting mechanisms. 378 Document Expiration: 28 February 1993 9 379 Generic Security Service API: Internet-Draft: August 1992 380 Common Authentication Technology WG: John Linn (DEC) 382 It is recommended that callers initiating contexts specify the 383 "default" mech_type value, allowing system-specific functions 384 within or invoked by the GSS-API implementation to select the 385 appropriate mech_type, but callers may direct that a particular 386 mech_type be employed when necessary. 388 The means for identifying a shared mech_type to establish a 389 security context with a peer will vary in different environments 390 and circumstances; examples include (but are not limited to): 392 o use of a fixed mech_type, defined by configuration, within an 393 environment 395 o syntactic convention on a target-specific basis, through 396 examination of a target's name 398 o lookup of a target's name in a naming service or other 399 database in order to identify mech_types supported by that 400 target 402 o explicit negotiation between GSS-API callers in advance of 403 security context setup 405 When transferred between GSS-API peers, mech_type specifiers 406 (per Appendix B, represented as Object Identifiers [3](OIDs)) 407 serve to qualify the interpretation of associated tokens. Use 408 of hierarchically structured OIDs serves to preclude ambiguous 409 interpretation of mech_type specifiers. The OID representing the 410 DASS MechType, for example, is 1.3.12.2.1011.7.5. 412 ___________________ 413 [3] The structure and encoding of Object Identifiers is defined in 414 ISO/IEC 8824, "Specification of Abstract Syntax Notation One 415 (ASN.1)" and in ISO/IEC 8825, "Specification of Basic Encoding 417 Rules for Abstract Syntax Notation One (ASN.1)". 419 10 Document Expiration: 28 February 1993 420 Generic Security Service API: Internet-Draft: August 1992 421 Common Authentication Technology WG: John Linn (DEC) 423 1.1.5 Naming 425 The GSS-API avoids prescription of naming structures, treating 426 the names transferred across the interface in order to initiate 427 and accept security contexts as opaque octet string quantities. 428 This approach supports the GSS-API's goal of implementability 429 atop a range of underlying security mechanisms, recognizing the 430 fact that different mechanisms process and authenticate names 431 which are presented in different forms. Generalized services 432 offering translation functions among arbitrary sets of naming 433 environments are outside the scope of the GSS-API; availability 434 and use of local conversion functions to translate among the 435 naming formats supported within a given end system is antici- 436 pated. 438 Two distinct classes of name representations are used in con- 439 junction with different GSS-API parameters: 441 o a printable form (denoted by OCTET STRING), for acceptance 442 from and presentation to users; printable name forms are 443 accompanied by OID tags identifying the namespace to which 444 they correspond 446 o an internal form (denoted by INTERNAL NAME), opaque to 447 callers and defined by individual GSS-API implementations; 448 GSS-API implementations supporting multiple namespace types 449 are responsible for maintaining internal tags to disambiguate 450 the interpretation of particular names 452 Tagging of printable names allows GSS-API callers and underlying 453 GSS-API mechanisms to disambiguate name types and to determine 454 whether an associated name's type is one which they are capable 455 of processing, avoiding aliasing problems which could result 456 from misinterpreting a name of one type as a name of another 457 type. 459 Document Expiration: 28 February 1993 11 460 Generic Security Service API: Internet-Draft: August 1992 461 Common Authentication Technology WG: John Linn (DEC) 463 In addition to providing means for names to be tagged with 464 types, this specification defines primitives to support a 465 level of naming environment independence for certain calling 466 applications. To provide basic services[4] oriented towards 467 the requirements of callers which need not themselves interpret 468 the internal syntax and semantics of names, GSS-API calls for 469 name comparison (GSS_Compare_name()), human-readable display 470 (GSS_Display_name()), input conversion (GSS_Import_name()), and 471 internal name deallocation (GSS_Release_name()) functions are 472 defined. 474 GSS_Import_name() implementations can, where appropriate, sup- 475 port more than one printable syntax corresponding to a given 476 namespace (e.g., alternative printable representations for X.500 477 Distinguished Names), allowing flexibility for their callers to 478 select among alternative representations. GSS_Display_name() 479 implementations output a printable syntax selected as appropri- 480 ate to their operational environments; this selection is a local 481 matter. Callers desiring portability across alternative print- 482 able syntaxes should refrain from implementing comparisons based 483 on printable name forms and should instead use the GSS_Compare_ 484 name() call to determine whether or not one internal-format 485 name matches another. 487 ___________________ 488 [4] It is anticipated that these proposed GSS-API calls will 489 be implemented in many end systems based on system-specific 490 name manipulation primitives already extant within those end 491 systems; inclusion within the GSS-API is intended to offer 492 GSS-API callers a portable means to perform specific opera- 493 tions, supportive of authorization and audit requirements, on 495 authenticated names. 497 12 Document Expiration: 28 February 1993 498 Generic Security Service API: Internet-Draft: August 1992 499 Common Authentication Technology WG: John Linn (DEC) 501 1.1.6 Channel Bindings 503 The GSS-API accommodates the concept of caller-provided channel 504 binding ("chan_binding") information, used by GSS-API callers 505 to bind the establishment of a security context to relevant 506 characteristics (e.g., addresses, transformed representations of 507 encryption keys) of the underlying communications channel and of 508 protection mechanisms applied to that communications channel. 509 Verification by one peer of chan_binding information provided by 510 the other peer to a context serves to protect against various 511 active attacks. The caller initiating a security context must 512 determine the chan_binding values before making the GSS_Init_ 513 sec_context() call, and consistent values must be provided 514 by both peers to a context. Callers should not assume that 515 underlying mechanisms provide confidentiality protection for 516 channel binding information. 518 Use or non-use of the GSS-API channel binding facility is a 519 caller option, and GSS-API supporting mechanisms can support 520 operation in an environment where NULL channel bindings are 521 presented. When non-NULL channel bindings are used, certain 522 mechanisms will offer enhanced security value by interpreting 523 the bindings' content (rather than simply representing those 524 bindings, or signatures computed on them, within tokens) and 525 will therefore depend on presentation of specific data in a 526 defined format. To this end, agreements among mechanism im- 527 plementors are defining[ 5] conventional interpretations for 528 the contents of channel binding arguments, including address 529 specifiers (with content dependent on communications protocol 530 environment) for context initiators and acceptors. In order 531 for GSS-API callers to be portable across multiple mechanisms 532 and achieve the full security functionality available from each 533 mechanism, it is strongly recommended that GSS-API callers pro- 534 vide channel bindings consistent with these conventions and 535 those of the networking environment in which they operate. 537 ___________________ 538 [ 5] These conventions are being incorporated into related 540 documents. 542 Document Expiration: 28 February 1993 13 543 Generic Security Service API: Internet-Draft: August 1992 544 Common Authentication Technology WG: John Linn (DEC) 546 1.2 GSS-API Features and Issues 548 This section describes aspects of GSS-API operations, of the 549 security services which the GSS-API provides, and provides 550 commentary on design issues. 552 1.2.1 Status Reporting 554 Each GSS-API call provides two status return values. Major_ 555 status values provide a mechanism-independent indication of call 556 status (e.g., GSS_COMPLETE, GSS_FAILURE, GSS_CONTINUE_NEEDED), 557 sufficient to drive normal control flow within the caller in 558 a generic fashion. Table 1 summarizes the defined major_status 559 return codes in tabular fashion. 561 ________________________________________________________________ 563 Table_1:__GSS-API_Major_Status_Codes____________________________ 565 FATAL ERROR CODES 567 GSS_BAD_BINDINGS channel binding mismatch 569 GSS_BAD_MECH unsupported mechanism requested 571 GSS_BAD_NAME invalid name provided 573 GSS_BAD_NAMETYPE name of unsupported type provided 575 GSS_BAD_STATUS invalid input status selector 577 GSS_BAD_SIG token had invalid signature 579 GSS_CONTEXT_EXPIRED specified security context expired 581 GSS_CREDENTIALS_EXPIRED expired credentials detected 583 14 Document Expiration: 28 February 1993 584 Generic Security Service API: Internet-Draft: August 1992 585 Common Authentication Technology WG: John Linn (DEC) 587 ________________________________________________________________ 589 Table_1_(Cont.):__GSS-API_Major_Status_Codes____________________ 591 GSS_DEFECTIVE_CREDENTIAL defective credential detected 593 GSS_DEFECTIVE_TOKEN defective token detected 595 GSS_FAILURE failure, unspecified at GSS-API 596 level 598 GSS_NO_CONTEXT no valid security context specified 600 GSS_NO_CRED no valid credentials provided 602 INFORMATORY STATUS CODES 604 GSS_COMPLETE normal completion 606 GSS_CONTINUE_NEEDED continuation call to routine re- 607 quired 609 GSS_DUPLICATE_TOKEN duplicate per-message token de- 610 tected 612 GSS_OLD_TOKEN timed-out per-message token de- 613 tected 615 GSS_UNSEQ_TOKEN out-of-order per-message token 616 _____________________________detected___________________________ 618 Minor_status provides more detailed status information which may 619 include status codes specific to the underlying security mecha- 620 nism. Minor_status values are not specified in this document. 622 GSS_CONTINUE_NEEDED major_status returns, and optional message 623 outputs, are provided in GSS_Init_sec_context() and GSS_Accept_ 624 sec_context() calls so that different mechanisms' employment 625 of different numbers of messages within their authentication 626 sequences need not be reflected in separate code paths within 628 Document Expiration: 28 February 1993 15 629 Generic Security Service API: Internet-Draft: August 1992 630 Common Authentication Technology WG: John Linn (DEC) 632 calling applications. Instead, such cases are accomodated with 633 sequences of continuation calls to GSS_Init_sec_context() and 634 GSS_Accept_sec_context(). The same mechanism is used to encap- 635 sulate mutual authentication within the GSS-API's context initi- 636 ation calls. In the graphic version of this document, Figure 3 637 illustrates a GSS-API continuation scenario. 639 For mech_types which require interactions with third-party 640 servers in order to establish a security context, GSS-API con- 641 text establishment calls may block pending completion of such 642 third-party interactions. On the other hand, no GSS-API calls 643 pend on serialized interactions with GSS-API peer entities. 644 As a result, local GSS-API status returns cannot reflect un- 645 predictable or asynchronous exceptions occurring at remote 646 peers, and reflection of such status information is a caller 647 responsibility outside the GSS-API. 649 1.2.2 Per-Message Security Service Availability 651 When a context is established, two flags are returned to indi- 652 cate the set of per-message protection security services which 653 will be available on the context: 655 o the integ_avail flag indicates whether per-message integrity 656 and data origin authentication services are available 658 o the conf_avail flag indicates whether per-message confiden- 659 tiality services are available, and will never be returned 660 TRUE unless the integ_avail flag is also returned TRUE 662 GSS-API callers desiring per-message security services should 663 check the values of these flags at context establishment time, 664 and must be aware that a returned FALSE value for integ_avail 665 means that invocation of GSS_Sign() or GSS_Seal() primitives on 666 the associated context will apply no cryptographic protection to 667 user data messages. 669 16 Document Expiration: 28 February 1993 670 Generic Security Service API: Internet-Draft: August 1992 671 Common Authentication Technology WG: John Linn (DEC) 673 The GSS-API per-message protection service primitives, as the 674 category name implies, are oriented to operation at the gran- 675 ulatity of protocol data units. They perform cryptographic 676 operations on the data units, transfer cryptographic control 677 information in tokens, and, in the case of GSS_Seal(), encap- 678 sulate the protected data unit. As such, these primitives are 679 not oriented to efficient data protection for stream-paradigm 680 protocols (e.g., Telnet) if cryptography must be applied on an 681 octet-by-octet basis. 683 1.2.3 Per-Message Replay Detection and Sequencing 685 Certain underlying mech_types are expected to offer support for 686 replay detection and/or sequencing of messages transferred on 687 the contexts they support. These optionally-selectable protec- 688 tion features are distinct from replay detection and sequencing 689 features applied to the context establishment operation itself; 690 the presence or absence of context-level replay or sequencing 691 features is wholly a function of the underlying mech_type's 692 capabilities, and is not selected or omitted as a caller option. 694 The caller initiating a context provides flags (replay_det_ 695 req_flag and sequence_req_flag) to specify whether the use of 696 per-message replay detection and sequencing features is desired 697 on the context being established. The GSS-API implementation 698 at the initiator system can determine whether these features 699 are supported (and whether they are optionally selectable) as a 700 function of mech_type, without need for bilateral negotiation 701 with the target. When enabled, these features provide recipients 702 with indicators as a result of GSS-API processing of incoming 703 messages, identifying whether those messages were detected as 704 duplicates or out-of-sequence. Detection of such events does not 705 prevent a suspect message from being provided to a recipient; 706 the appropriate course of action on a suspect message is a 707 matter of caller policy. 709 Document Expiration: 28 February 1993 17 710 Generic Security Service API: Internet-Draft: August 1992 711 Common Authentication Technology WG: John Linn (DEC) 713 The semantics of the replay detection and sequencing services 714 applied to received messages, as visible across the interface 715 which the GSS-API provides to its clients, are as follows: 717 When replay_det_state is TRUE, the possible major_status returns 718 for well-formed and correctly signed messages are as follows: 720 1. GSS_COMPLETE indicates that the message was within the win- 721 dow (of time or sequence space) allowing replay events to 722 be detected, and that the message was not a replay of a 723 previously-processed message within that window. 725 2. GSS_DUPLICATE_TOKEN indicates that the signature on the re- 726 ceived message was correct, but that the message was recog- 727 nized as a duplicate of a previously-processed message. 729 3. GSS_OLD_TOKEN indicates that the signature on the received 730 message was correct, but that the message is too old to be 731 checked for duplication. 733 When sequence_state is TRUE, the possible major_status returns 734 for well-formed and correctly signed messages are as follows: 736 1. GSS_COMPLETE indicates that the message was within the win- 737 dow (of time or sequence space) allowing replay events to 738 be detected, and that the message was not a replay of a 739 previously-processed message within that window. 741 2. GSS_DUPLICATE_TOKEN indicates that the signature on the re- 742 ceived message was correct, but that the message was recog- 743 nized as a duplicate of a previously-processed message. 745 3. GSS_OLD_TOKEN indicates that the signature on the received 746 message was correct, but that the token is too old to be 747 checked for duplication. 749 18 Document Expiration: 28 February 1993 750 Generic Security Service API: Internet-Draft: August 1992 751 Common Authentication Technology WG: John Linn (DEC) 753 4. GSS_UNSEQ_TOKEN indicates that the signature on the received 754 message was correct, but that it is earlier in a sequenced 755 stream [6] than a message already processed on the context. 757 As the message stream integrity features (especially sequencing) 758 may interfere with certain applications' intended communications 759 paradigms, and since support for such features is likely to be 760 resource intensive, it is highly recommended that mech_types 761 supporting these features allow them to be activated selectively 762 on initiator request when a context is established. A context 763 initiator and target are provided with corresponding indicators 764 (replay_det_state and sequence_state), signifying whether these 765 features are active on a given context. 767 An example mech_type supporting per-message replay detection 768 could (when replay_det_state is TRUE) implement the feature as 769 follows: The underlying mechanism would insert timestamps in 770 data elements output by GSS_Sign() and GSS_Seal(), and would 771 maintain (within a time-limited window) a cache (qualified by 772 originator-recipient pair) identifying received data elements 773 processed by GSS_Verify() and GSS_Unseal(). When this feature 774 is active, exception status returns (GSS_DUPLICATE_TOKEN, GSS_ 775 OLD_TOKEN) will be provided when GSS_Verify() or GSS_Unseal() 776 is presented with a message which is either a detected duplicate 778 ___________________ 779 [6] Mechanisms can be architected to provide a stricter form of 780 sequencing service, delivering particular messages to recipi- 781 ents only after all predecessor messages in an ordered stream 782 have been delivered. This type of support is incompatible 783 with the GSS-API paradigm in which recipients receive all mes- 784 sages, whether in order or not, and provide them (one at a 785 time, without intra-GSS-API message buffering) to GSS-API rou- 786 tines for validation. GSS-API facilities provide supportive 787 functions, aiding clients to achieve strict message stream in- 788 tegrity in an efficient manner in conjunction with sequencing 789 provisions in communications protocols, but the GSS-API does 790 not offer this level of message stream integrity service by 792 itself. 794 Document Expiration: 28 February 1993 19 795 Generic Security Service API: Internet-Draft: August 1992 796 Common Authentication Technology WG: John Linn (DEC) 798 of a prior message or which is too old to validate against a 799 cache of recently received messages. 801 1.2.4 Quality of Protection 803 Some mech_types will provide their users with fine granularity 804 control over the means used to provide per-message protection, 805 allowing callers to trade off security processing overhead dy- 806 namically against the protection requirements of particular 807 messages. A per-message quality-of-protection parameter (anal- 808 ogous to quality-of-service, or QOS) selects among different 809 QOP options supported by that mechanism. On context establish- 810 ment for a multi-QOP mech_type, context-level data provides the 811 prerequisite data for a range of protection qualities. 813 It is expected that the majority of callers will not wish to 814 exert explicit mechanism-specific QOP control and will therefore 815 request selection of a default QOP. Definitions of, and choices 816 among, non-default QOP values are mechanism-specific, and no 817 ordered sequences of QOP values can be assumed equivalent across 818 different mechanisms. Meaningful use of non-default QOP values 819 demands that callers be familiar with the QOP definitions of 820 an underlying mechanism or mechanisms, and is therefore a non- 821 portable construct. 823 2 Interface Descriptions 825 This section describes the GSS-API's service interface, dividing 826 the set of calls offered into four groups. Credential management 827 calls are related to the acquisition and release of credentials 828 by principals. Context-level calls are related to the management 829 of security contexts between principals. Per-message calls are 830 related to the protection of individual messages on established 831 security contexts. Support calls provide ancillary functions 832 useful to GSS-API callers. Table 2 groups and summarizes the 833 calls in tabular fashion. 835 20 Document Expiration: 28 February 1993 836 Generic Security Service API: Internet-Draft: August 1992 837 Common Authentication Technology WG: John Linn (DEC) 839 ________________________________________________________________ 841 Table_2:__GSS-API_Calls_________________________________________ 843 CREDENTIAL MANAGEMENT 845 GSS_Acquire_cred acquire credentials for use 847 GSS_Release_cred release credentials after use 849 GSS_Inquire_cred display information about creden- 850 tials 852 CONTEXT-LEVEL CALLS 854 GSS_Init_sec_context initiate outbound security context 856 GSS_Accept_sec_context accept inbound security context 858 GSS_Delete_sec_context flush context when no longer needed 860 GSS_Process_context_token process received control token on 861 context 863 GSS_Context_time indicate validity time remaining on 864 context 866 PER-MESSAGE CALLS 868 GSS_Sign apply signature, receive as token 869 separate from message 871 GSS_Verify validate signature token along with 872 message 874 GSS_Seal sign, optionally encrypt, encapsu- 875 late 877 Document Expiration: 28 February 1993 21 878 Generic Security Service API: Internet-Draft: August 1992 879 Common Authentication Technology WG: John Linn (DEC) 881 ________________________________________________________________ 883 Table_2_(Cont.):__GSS-API_Calls_________________________________ 885 GSS_Unseal decapsulate, decrypt if needed, 886 validate signature 888 SUPPORT CALLS 890 GSS_Display_status translate status codes to printable 891 form 893 GSS_Indicate_mechs indicate mech_types supported on 894 local system 896 GSS_Compare_name compare two names for equality 898 GSS_Display_name translate name to printable form 900 GSS_Import_name convert printable name to normal- 901 ized form 903 GSS_Release_name free storage of normalized-form 904 name 906 GSS_Release_buffer free storage of printable name 908 GSS_Release_oid_set__________free_storage_of_OID_set_object_____ 910 2.1 Credential management calls 912 These GSS-API calls provide functions related to the management 913 of credentials. Their characterization with regard to whether or 914 not they may block pending exchanges with other network entities 915 (e.g., directories or authentication servers) depends in part on 916 OS-specific (extra-GSS-API) issues, so is not specified in this 917 document. 919 22 Document Expiration: 28 February 1993 920 Generic Security Service API: Internet-Draft: August 1992 921 Common Authentication Technology WG: John Linn (DEC) 923 The GSS_Acquire_cred() call is defined within the GSS-API in 924 support of application portability, with a particular orien- 925 tation towards support of portable server applications. It is 926 recognized that (for certain systems and mechanisms) creden- 927 tials for interactive users may be managed differently from 928 credentials for server processes; in such environments, it is 929 the GSS-API implementation's responsibility to distinguish these 930 cases and the procedures for making this distinction are a lo- 931 cal matter. The GSS_Release_cred() call provides a means for 932 callers to indicate to the GSS-API that use of a credentials 933 structure is no longer required. The GSS_Inquire_cred() call 934 allows callers to determine information about a credentials 935 structure. 937 2.1.1 GSS_Acquire_cred call 939 Inputs: 941 o desired_name INTERNAL NAME, -NULL requests locally-determined 942 default 944 o lifetime_req INTEGER,-in seconds; 0 requests default 946 o desired_mechs SET OF OBJECT IDENTIFIER,-empty set requests 947 system-selected default 949 o cred_usage INTEGER-0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, 950 2=ACCEPT-ONLY 952 Outputs: 954 o major_status INTEGER, 956 o minor_status INTEGER, 958 o output_cred_handle OCTET STRING, 960 o lifetime_rec INTEGER -in seconds, or reserved value for 961 INDEFINITE 963 Document Expiration: 28 February 1993 23 964 Generic Security Service API: Internet-Draft: August 1992 965 Common Authentication Technology WG: John Linn (DEC) 967 Return major_status codes: 969 o GSS_COMPLETE indicates that requested credentials were suc- 970 cessfully established, for the duration indicated in life- 971 time_rec, suitable for the usage requested in cred_usage, 972 and for all or a subset of the requested mech_types, and that 973 those credentials can be referenced for subsequent use with 974 the handle returned in output_cred_handle. 976 o GSS_BAD_MECH indicates that a mech_type unsupported by the 977 GSS-API implementation type was requested, causing the cre- 978 dential establishment operation to fail. 980 o GSS_BAD_NAMETYPE indicates that the provided desired_name is 981 uninterpretable or of a type unsupported by the supporting 982 GSS-API implementation, so no credentials could be estab- 983 lished for the accompanying desired_name. 985 o GSS_BAD_NAME indicates that the provided desired_name is in- 986 consistent in terms of internally-incorporated type specifier 987 information, so no credentials could be established for the 988 accompanying desired_name. 990 o GSS_FAILURE indicates that credential establishment failed 991 for reasons unspecified at the GSS-API level, including lack 992 of authorization to establish and use credentials associated 993 with the identity named in the input desired_name argument. 995 GSS_Acquire_cred() is used to acquire credentials so that a 996 principal can (as a function of the input cred_usage parameter) 997 initiate and/or accept security contexts under the identity 998 represented by the desired_name input argument. On successful 999 completion, the returned output_cred_handle result provides a 1000 handle for subsequent references to the acquired credentials. 1001 Typically, single-user client processes using only default 1002 credentials for context establishment purposes will have no 1003 need to invoke this call. 1005 24 Document Expiration: 28 February 1993 1006 Generic Security Service API: Internet-Draft: August 1992 1007 Common Authentication Technology WG: John Linn (DEC) 1009 A caller may provide the value NULL for desired_name, signifying 1010 a request for credentials corresponding to a default princi- 1011 pal identity. The procedures used by GSS-API implementations to 1012 select the appropriate principal identity in response to this 1013 form of request are local matters. It is possible that multiple 1014 pre-established credentials may exist for the same principal 1015 identity (for example, as a result of multiple user login ses- 1016 sions) when GSS_Acquire_cred() is called; the means used in 1017 such cases to select a specific credential are local matters[7]. 1019 The lifetime_rec result indicates the length of time for which 1020 the acquired credentials will be valid, as an offset from the 1021 present. A mechanism may return a reserved value indicating IN- 1022 DEFINITE if no constraints on credential lifetime are imposed. 1023 A caller of GSS_Acquire_cred() can request a length of time for 1024 which acquired credentials are to be valid (lifetime_req argu- 1025 ment), beginning at the present[8], or can request credentials 1026 with a default validity interval. Certain mechanisms and im- 1027 plementations may bind in credential validity period specifiers 1028 at a point preliminary to invocation of the GSS_Acquire_cred() 1029 call (e.g., in conjunction with user login procedures). As a 1030 result, callers requesting non-default values for lifetime_req 1031 must recognize that such requests cannot always be honored and 1032 must be prepared to accommodate the use of returned credentials 1033 with different lifetimes as indicated in lifetime_rec. 1035 The caller of GSS_Acquire_cred() can explicitly specify a set 1036 of mech_types which are to be accommodated in the returned 1037 credentials (desired_mechs argument), or can request credentials 1038 for a system-defined default set of mech_types. Selection of the 1039 system-specified default set is recommended in the interests of 1040 application_portability. 1042 [7] The input lifetime_req argument to GSS_Acquire_cred() may 1043 provide useful information for local GSS-API implementations 1044 to employ in making this disambiguation in a manner which will 1046 best satisfy a caller's intent. 1047 [8] Requests for postdated credentials are not supported within 1049 the GSS-API. 1051 Document Expiration: 28 February 1993 25 1052 Generic Security Service API: Internet-Draft: August 1992 1053 Common Authentication Technology WG: John Linn (DEC) 1055 2.1.2 GSS_Release_cred call 1057 Input: 1059 o cred_handle OCTET STRING-NULL specifies default credentials 1061 Outputs: 1063 o major_status INTEGER, 1065 o minor_status INTEGER 1067 Return major_status codes: 1069 o GSS_COMPLETE indicates that the credentials referenced by the 1070 input cred_handle were released for purposes of subsequent 1071 access by the caller. The effect on other processes which may 1072 be authorized shared access to such credentials is a local 1073 matter. 1075 o GSS_NO_CRED indicates that no release operation was per- 1076 formed, either because the input cred_handle was invalid or 1077 because the caller lacks authorization to access the refer- 1078 enced credentials. 1080 o GSS_FAILURE indicates that the release operation failed for 1081 reasons unspecified at the GSS-API level. 1083 Provides a means for a caller to explicitly request that cre- 1084 dentials be released when their use is no longer required. Note 1085 that system-specific credential management functions are also 1086 likely to exist, for example to assure that credentials shared 1087 among processes are properly deleted when all affected processes 1088 terminate, even if no explicit release requests are issued by 1089 those processes. Given the fact that multiple callers are not 1090 precluded from gaining authorized access to the same creden- 1091 tials, invocation of GSS_Release_cred() cannot be assumed to 1092 delete a particular set of credentials on a system-wide basis. 1094 26 Document Expiration: 28 February 1993 1095 Generic Security Service API: Internet-Draft: August 1992 1096 Common Authentication Technology WG: John Linn (DEC) 1098 2.1.3 GSS_Inquire_cred call 1100 Input: 1102 o cred_handle OCTET STRING-NULL specifies default credentials 1104 Outputs: 1106 o major_status INTEGER, 1108 o minor_status INTEGER, 1110 o cred_name INTERNAL NAME, 1112 o lifetime_rec INTEGER-in seconds, or reserved value for INDEF- 1113 INITE 1115 o cred_usage INTEGER,-0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, 1116 2=ACCEPT-ONLY 1118 o mech_set SET OF OBJECT IDENTIFIER 1120 Return major_status codes: 1122 o GSS_COMPLETE indicates that the credentials referenced by the 1123 input cred_handle argument were valid, and that the output 1124 cred_name, lifetime_rec, and cred_usage values represent, 1125 respectively, the credentials' associated principal name, 1126 remaining lifetime, suitable usage modes, and supported 1127 mechanism types. 1129 o GSS_NO_CRED indicates that no information could be returned 1130 about the referenced credentials, either because the input 1131 cred_handle was invalid or because the caller lacks autho- 1132 rization to access the referenced credentials. 1134 o GSS_FAILURE indicates that the release operation failed for 1135 reasons unspecified at the GSS-API level. 1137 The GSS_Inquire_cred() call is defined primarily for the use 1138 of those callers which make use of default credentials rather 1139 than acquiring credentials explicitly with GSS_Acquire_cred(). 1140 It enables callers to determine a credential structure's asso- 1141 ciated principal name, remaining validity period, usability for 1143 Document Expiration: 28 February 1993 27 1144 Generic Security Service API: Internet-Draft: August 1992 1145 Common Authentication Technology WG: John Linn (DEC) 1147 security context initiation and/or acceptance, and supported 1148 mechanisms. 1150 2.2 Context-level calls 1152 This group of calls is devoted to the establishment and manage- 1153 ment of security contexts between peers. A context's initiator 1154 calls GSS_Init_sec_context(), resulting in generation of a to- 1155 ken which the caller passes to the target. At the target, that 1156 token is passed to GSS_Accept_sec_context(). Depending on the 1157 underlying mech_type and specified options, additional token 1158 exchanges may be performed in the course of context establish- 1159 ment; such exchanges are accommodated by GSS_CONTINUE_NEEDED 1160 status returns from GSS_Init_sec_context() and GSS_Accept_sec_ 1161 context(). Either party to an established context may invoke 1162 GSS_Delete_sec_context() to flush context information when a 1163 context is no longer required. GSS_Process_context_token() is 1164 used to process received tokens carrying context-level control 1165 information. GSS_Context_time() allows a caller to determine 1166 the length of time for which an established context will remain 1167 valid. 1169 2.2.1 GSS_Init_sec_context call 1171 Inputs: 1173 o claimant_cred_handle OCTET STRING, -NULL specifies "use 1174 default" 1176 o input_context_handle INTEGER, -0 specifies "none assigned 1177 yet" 1179 o targ_name INTERNAL NAME, 1181 o mech_type OBJECT IDENTIFIER, -NULL parameter specifies "use 1182 default" 1184 o deleg_req_flag BOOLEAN, 1186 o mutual_req_flag BOOLEAN, 1188 28 Document Expiration: 28 February 1993 1189 Generic Security Service API: Internet-Draft: August 1992 1190 Common Authentication Technology WG: John Linn (DEC) 1192 o replay_det_req_flag BOOLEAN, 1194 o sequence_req_flag BOOLEAN, 1196 o lifetime_req INTEGER,-0 specifies default lifetime 1198 o chan_bindings OCTET STRING, 1200 o input_token OCTET STRING-NULL or token received from target 1202 Outputs: 1204 o major_status INTEGER, 1206 o minor_status INTEGER, 1208 o output_context_handle INTEGER, 1210 o mech_type OBJECT IDENTIFIER, -actual mechanism always indi- 1211 cated, never NULL 1213 o output_token OCTET STRING, -NULL or token to pass to context 1214 target 1216 o deleg_state BOOLEAN, 1218 o mutual_state BOOLEAN, 1220 o replay_det_state BOOLEAN, 1222 o sequence_state BOOLEAN, 1224 o conf_avail BOOLEAN, 1226 o integ_avail BOOLEAN, 1228 o lifetime_rec INTEGER - in seconds, or reserved value for 1229 INDEFINITE 1231 This call may block pending network interactions for those mech_ 1232 types in which an authentication server or other network entity 1233 must be consulted on behalf of a context initiator in order 1234 to generate an output_token suitable for presentation to a 1235 specified target. 1237 Document Expiration: 28 February 1993 29 1238 Generic Security Service API: Internet-Draft: August 1992 1239 Common Authentication Technology WG: John Linn (DEC) 1241 Return major_status codes: 1243 o GSS_COMPLETE indicates that context-level information was 1244 successfully initialized, and that the returned output_token 1245 will provide sufficient information for the target to perform 1246 per-message processing on the newly-established context. 1248 o GSS_CONTINUE_NEEDED indicates that control information in the 1249 returned output_token must be sent to the target, and that a 1250 reply must be received and passed as the input_token argument 1251 to a continuation call to GSS_Init_sec_context(), before 1252 per-message processing can be performed in conjunction with 1253 this context. 1255 o GSS_DEFECTIVE_TOKEN indicates that consistency checks per- 1256 formed on the input_token failed, preventing further process- 1257 ing from being performed based on that token. 1259 o GSS_DEFECTIVE_CREDENTIAL indicates that consistency checks 1260 performed on the credential structure referenced by claimant_ 1261 cred_handle failed, preventing further processing from being 1262 performed using that credential structure. 1264 o GSS_BAD_SIG indicates that the received input_token con- 1265 tains an incorrect signature, so context setup cannot be 1266 accomplished. 1268 o GSS_NO_CRED indicates that no context was established, ei- 1269 ther because the input cred_handle was invalid, because the 1270 referenced credentials are valid for context acceptor use 1271 only, or because the caller lacks authorization to access the 1272 referenced credentials. 1274 o GSS_CREDENTIALS_EXPIRED indicates that the credentials pro- 1275 vided through the input claimant_cred_handle argument are no 1276 longer valid, so context establishment cannot be completed. 1278 o GSS_BAD_BINDINGS indicates that a mismatch between the 1279 caller-provided chan_bindings and those extracted from the 1280 input_token was detected, signifying a security-relevant 1281 event and preventing context establishment. (This result will 1283 30 Document Expiration: 28 February 1993 1284 Generic Security Service API: Internet-Draft: August 1992 1285 Common Authentication Technology WG: John Linn (DEC) 1287 be returned by GSS_Init_sec_context only for contexts where 1288 mutual_state is TRUE.) 1290 o GSS_NO_CONTEXT indicates that no valid context was recognized 1291 for the input context_handle provided; this major status will 1292 be returned only for successor calls following GSS_CONTINUE_ 1293 NEEDED status returns. 1295 o GSS_BAD_NAMETYPE indicates that the provided targ_name is 1296 of a type uninterpretable or unsupported by the supporting 1297 GSS-API implementation, so context establishment cannot be 1298 completed. 1300 o GSS_BAD_NAME indicates that the provided targ_name is incon- 1301 sistent in terms of internally-incorporated type specifier 1302 information, so context establishment cannot be accomplished. 1304 o GSS_FAILURE indicates that context setup could not be ac- 1305 complished for reasons unspecified at the GSS-API level, and 1306 that no interface-defined recovery action is available. 1308 This routine is used by a context initiator, and ordinarily 1309 emits one (or, for the case of a multi-step exchange, more than 1310 one) output_token suitable for use by the target within the 1311 selected mech_type's protocol. Using information in the creden- 1312 tials structure referenced by claimant_cred_handle, GSS_Init_ 1313 sec_context() initializes the data structures required to es- 1314 tablish a security context with target targ_name. The claimant_ 1315 cred_handle must correspond to the same valid credentials struc- 1316 ture on the initial call to GSS_Init_sec_context() and on any 1317 successor calls resulting from GSS_CONTINUE_NEEDED status re- 1318 turns; different protocol sequences modeled by the GSS_CONTINUE_ 1319 NEEDED mechanism will require access to credentials at different 1320 points in the context establishment sequence. 1322 The input_context_handle argument is 0, specifying "not yet as- 1323 signed", on the first GSS_Init_sec_context() call relating to 1324 a given context. That call returns an output_context_handle for 1325 future references to this context. When continuation attempts to 1327 Document Expiration: 28 February 1993 31 1328 Generic Security Service API: Internet-Draft: August 1992 1329 Common Authentication Technology WG: John Linn (DEC) 1331 GSS_Init_sec_context() are needed to perform context establish- 1332 ment, the previously-returned non-zero handle value is entered 1333 into the input_context_handle argument and will be echoed in the 1334 returned output_context_handle argument. On such continuation 1335 attempts (and only on continuation attempts) the input_token 1336 value is used, to provide the token returned from the context's 1337 target. 1339 The chan_bindings argument is used by the caller to provide 1340 information binding the security context to security-related 1341 characteristics (e.g., addresses, cryptographic keys) of the 1342 underlying communications channel. See Section 1.1.6 of this 1343 document for more discussion of this argument's usage. 1345 The input_token argument contains a message received from the 1346 target, and is significant only on a call to GSS_Init_sec_ 1347 context() which follows a previous return indicating GSS_ 1348 CONTINUE_NEEDED major_status. 1350 It is the caller's responsibility to establish a communications 1351 path to the target, and to transmit any returned output_token 1352 (independent of the accompanying returned major_status value) 1353 to the target over that path. The output_token can, however, be 1354 transmitted along with the first application-provided input mes- 1355 sage to be processed by GSS_Sign() or GSS_Seal() in conjunction 1356 with a successfully-established context. 1358 The initiator may request various context-level functions 1359 through input flags: the deleg_req_flag requests delegation 1360 of access rights, the mutual_req_flag requests mutual authenti- 1361 cation, the replay_det_req_flag requests that replay detection 1362 features be applied to messages transferred on the established 1363 context, and the sequence_req_flag requests that sequencing 1364 be enforced. (See Section 1.2.3 for more information on replay 1365 detection and sequencing features.) 1367 32 Document Expiration: 28 February 1993 1368 Generic Security Service API: Internet-Draft: August 1992 1369 Common Authentication Technology WG: John Linn (DEC) 1371 Not all of the optionally-requestable features will be available 1372 in all underlying mech_types; the corresponding return state 1373 values (deleg_state, mutual_state, replay_det_state, sequence_ 1374 state) indicate, as a function of mech_type processing capabil- 1375 ities and initiator-provided input flags, the set of features 1376 which will be active on the context. These state indicators' 1377 values are undefined unless the routine's major_status indi- 1378 cates COMPLETE. Failure to provide the precise set of features 1379 requested by the caller does not cause context establishment 1380 to fail; it is the caller's prerogative to delete the context 1381 if the feature set provided is unsuitable for the caller's use. 1382 The returned mech_type value indicates the specific mechanism 1383 employed on the context, and will never indicate the value for 1384 "default". 1386 The conf_avail return value indicates whether the context sup- 1387 ports per-message confidentiality services, and so informs the 1388 caller whether or not a request for encryption through the conf_ 1389 req_flag input to GSS_Seal() can be honored. In similar fash- 1390 ion, the integ_avail return value indicates whether per-message 1391 integrity services are available (through either GSS_Sign() or 1392 GSS_Seal()) on the established context. 1394 The lifetime_req input specifies a desired upper bound for the 1395 lifetime of the context to be established, with a value of 0 1396 used to request a default lifetime. The lifetime_rec return 1397 value indicates the length of time for which the context will 1398 be valid, expressed as an offset from the present; depending on 1399 mechanism capabilities, credential lifetimes, and local policy, 1400 it may not correspond to the value requested in lifetime_req. 1401 If no constraints on context lifetime are imposed, this may be 1402 indicated by returning a reserved value representing INDEFI- 1403 NITE lifetime_req. The values of conf_avail, integ_avail, and 1404 lifetime_rec are undefined unless the routine's major_status 1405 indicates COMPLETE. 1407 Document Expiration: 28 February 1993 33 1408 Generic Security Service API: Internet-Draft: August 1992 1409 Common Authentication Technology WG: John Linn (DEC) 1411 If the mutual_state is TRUE, this fact will be reflected within 1412 the output_token. A call to GSS_Accept_sec_context() at the 1413 target in conjunction with such a context will return a to- 1414 ken, to be processed by a continuation call to GSS_Init_sec_ 1415 context(), in order to achieve mutual authentication. 1417 2.2.2 GSS_Accept_sec_context call 1419 Inputs: 1421 o acceptor_cred_handle OCTET STRING,-NULL specifies "use de- 1422 fault" 1424 o input_context_handle INTEGER, -0 specifies "not yet assigned" 1426 o chan_bindings OCTET STRING, 1428 o input_token OCTET STRING 1430 Outputs: 1432 o major_status INTEGER, 1434 o minor_status INTEGER, 1436 o src_name INTERNAL NAME, 1438 o mech_type OBJECT IDENTIFIER, 1440 o output_context_handle INTEGER, 1442 o deleg_state BOOLEAN, 1444 o mutual_state BOOLEAN, 1446 o replay_det_state BOOLEAN, 1448 o sequence_state BOOLEAN, 1450 o conf_avail BOOLEAN, 1452 o integ_avail BOOLEAN, 1454 o lifetime_rec INTEGER, - in seconds, or reserved value for 1455 INDEFINITE 1457 34 Document Expiration: 28 February 1993 1458 Generic Security Service API: Internet-Draft: August 1992 1459 Common Authentication Technology WG: John Linn (DEC) 1461 o delegated_cred_handle OCTET STRING, 1463 o output_token OCTET STRING -NULL or token to pass to context 1464 initiator 1466 This call may block pending network interactions for those 1467 mech_types in which a directory service or other network entity 1468 must be consulted on behalf of a context acceptor in order to 1469 validate a received input_token. 1471 Return major_status codes: 1473 o GSS_COMPLETE indicates that context-level data structures 1474 were successfully initialized, and that per-message process- 1475 ing can now be performed in conjunction with this context. 1477 o GSS_CONTINUE_NEEDED indicates that control information in the 1478 returned output_token must be sent to the initiator, and that 1479 a response must be received and passed as the input_token 1480 argument to a continuation call to GSS_Accept_sec_context(), 1481 before per-message processing can be performed in conjunction 1482 with this context. 1484 o GSS_DEFECTIVE_TOKEN indicates that consistency checks per- 1485 formed on the input_token failed, preventing further process- 1486 ing from being performed based on that token. 1488 o GSS_DEFECTIVE_CREDENTIAL indicates that consistency checks 1489 performed on the credential structure referenced by acceptor_ 1490 cred_handle failed, preventing further processing from being 1491 performed using that credential structure. 1493 o GSS_BAD_SIG indicates that the received input_token con- 1494 tains an incorrect signature, so context setup cannot be 1495 accomplished. 1497 o GSS_DUPLICATE_TOKEN indicates that the signature on the 1498 received input_token was correct, but that the input_token 1499 was recognized as a duplicate of an input_token already 1500 processed. No new context is established. 1502 Document Expiration: 28 February 1993 35 1503 Generic Security Service API: Internet-Draft: August 1992 1504 Common Authentication Technology WG: John Linn (DEC) 1506 o GSS_OLD_TOKEN indicates that the signature on the received 1507 input_token was correct, but that the input_token is too old 1508 to be checked for duplication against previously-processed 1509 input_tokens. No new context is established. 1511 o GSS_NO_CRED indicates that no context was established, ei- 1512 ther because the input cred_handle was invalid, because the 1513 referenced credentials are valid for context initiator use 1514 only, or because the caller lacks authorization to access the 1515 referenced credentials. 1517 o GSS_CREDENTIALS_EXPIRED indicates that the credentials pro- 1518 vided through the input acceptor_cred_handle argument are no 1519 longer valid, so context establishment cannot be completed. 1521 o GSS_BAD_BINDINGS indicates that a mismatch between the 1522 caller-provided chan_bindings and those extracted from the 1523 input_token was detected, signifying a security-relevant 1524 event and preventing context establishment. 1526 o GSS_NO_CONTEXT indicates that no valid context was recognized 1527 for the input context_handle provided; this major status will 1528 be returned only for successor calls following GSS_CONTINUE_ 1529 NEEDED status returns. 1531 o GSS_FAILURE indicates that context setup could not be ac- 1532 complished for reasons unspecified at the GSS-API level, and 1533 that no interface-defined recovery action is available. 1535 The GSS_Accept_sec_context() routine is used by a context tar- 1536 get. Using information in the credentials structure referenced 1537 by the input acceptor_cred_handle, it verifies the incoming in- 1538 put_token and (following the successful completion of a context 1539 establishment sequence) returns the authenticated src_name and 1540 the mech_type used. The acceptor_cred_handle must correspond to 1541 the same valid credentials structure on the initial call to GSS_ 1542 Accept_sec_context() and on any successor calls resulting from 1543 GSS_CONTINUE_NEEDED status returns; different protocol sequences 1544 modeled by the GSS_CONTINUE_NEEDED mechanism will require access 1546 36 Document Expiration: 28 February 1993 1547 Generic Security Service API: Internet-Draft: August 1992 1548 Common Authentication Technology WG: John Linn (DEC) 1550 to credentials at different points in the context establishment 1551 sequence. 1553 The input_context_handle argument is 0, specifying "not yet as- 1554 signed", on the first GSS_Accept_sec_context() call relating to 1555 a given context. That call returns an output_context_handle for 1556 future references to this context; when continuation attempts 1557 to GSS_Accept_sec_context() are needed to perform context es- 1558 tablishment, that handle value will be entered into the input_ 1559 context_handle argument. 1561 The chan_bindings argument is used by the caller to provide 1562 information binding the security context to security-related 1563 characteristics (e.g., addresses, cryptographic keys) of the 1564 underlying communications channel. See Section 1.1.6 of this 1565 document for more discussion of this argument's usage. 1567 The returned state results (deleg_state, mutual_state, replay_ 1568 det_state, and sequence_state) reflect the same context state 1569 values as returned to GSS_Init_sec_context()'s caller at the 1570 initiator system. 1572 The conf_avail return value indicates whether the context sup- 1573 ports per-message confidentiality services, and so informs the 1574 caller whether or not a request for encryption through the conf_ 1575 req_flag input to GSS_Seal() can be honored. In similar fash- 1576 ion, the integ_avail return value indicates whether per-message 1577 integrity services are available (through either GSS_Sign() or 1578 GSS_Seal()) on the established context. 1580 The lifetime_rec return value indicates the length of time for 1581 which the context will be valid, expressed as an offset from the 1582 present. The values of deleg_state, mutual_state, replay_det_ 1583 state, sequence_state, conf_avail, integ_avail, and lifetime_rec 1584 are undefined unless the accompanying major_status indicates 1585 COMPLETE. 1587 Document Expiration: 28 February 1993 37 1588 Generic Security Service API: Internet-Draft: August 1992 1589 Common Authentication Technology WG: John Linn (DEC) 1591 The delegated_cred_handle result is significant only when deleg_ 1592 state is TRUE, and provides a means for the target to reference 1593 the delegated credentials. The output_token result, when non- 1594 NULL, provides a context-level token to be returned to the 1595 context initiator to continue a multi-step context establishment 1596 sequence. As noted with GSS_Init_sec_context(), any returned 1597 token should be transferred to the context's peer (in this 1598 case, the context initiator), independent of the value of the 1599 accompanying returned major_status. 1601 Note: A target must be able to distinguish a context-level in- 1602 put_token, which is passed to GSS_Accept_sec_context(), from 1603 the per-message data elements passed to GSS_Verify() or GSS_ 1604 Unseal(). These data elements may arrive in a single applica- 1605 tion message, and GSS_Accept_sec_context() must be performed 1606 before per-message processing can be performed successfully. 1608 2.2.3 GSS_Delete_sec_context call 1610 Input: 1612 o context_handle INTEGER 1614 Outputs: 1616 o major_status INTEGER, 1618 o minor_status INTEGER, 1620 o output_context_token OCTET STRING 1622 Return major_status codes: 1624 o GSS_COMPLETE indicates that the context was recognized, that 1625 relevant context-specific information was flushed, and that 1626 the returned output_context_token is ready for transfer to 1627 the context's peer. 1629 o GSS_NO_CONTEXT indicates that no valid context was recognized 1630 for the input context_handle provide, so no deletion was 1631 performed. 1633 38 Document Expiration: 28 February 1993 1634 Generic Security Service API: Internet-Draft: August 1992 1635 Common Authentication Technology WG: John Linn (DEC) 1637 o GSS_FAILURE indicates that the context is recognized, but 1638 that the GSS_Delete_sec_context() operation could not be 1639 performed for reasons unspecified at the GSS-API level. 1641 This call may block pending network interactions for mech_types 1642 in which active notification must be made to a central server 1643 when a security context is to be deleted. 1645 This call can be made by either peer in a security context, 1646 to flush context-specific information and to return an output_ 1647 context_token which can be passed to the context's peer in- 1648 forming it that the peer's corresponding context information 1649 can also be flushed. (Once a context is established, the peers 1650 involved are expected to retain cached credential and context- 1651 related information until the information's expiration time is 1652 reached or until a GSS_Delete_sec_context() call is made.) At- 1653 tempts to perform per-message processing on a deleted context 1654 will result in error returns. 1656 2.2.4 GSS_Process_context_token call 1658 Inputs: 1660 o context_handle INTEGER, 1662 o input_context_token OCTET STRING 1664 Outputs: 1666 o major_status INTEGER, 1668 o minor_status INTEGER, 1670 Return major_status codes: 1672 o GSS_COMPLETE indicates that the input_context_token was suc- 1673 cessfully processed in conjunction with the context refer- 1674 enced by context_handle. 1676 o GSS_DEFECTIVE_TOKEN indicates that consistency checks per- 1677 formed on the received context_token failed, preventing 1678 further processing from being performed with that token. 1680 Document Expiration: 28 February 1993 39 1681 Generic Security Service API: Internet-Draft: August 1992 1682 Common Authentication Technology WG: John Linn (DEC) 1684 o GSS_NO_CONTEXT indicates that no valid context was recognized 1685 for the input context_handle provided. 1687 o GSS_FAILURE indicates that the context is recognized, but 1688 that the GSS_Process_context_token() operation could not be 1689 performed for reasons unspecified at the GSS-API level. 1691 This call is used to process context_tokens received from a peer 1692 once a context has been established, with corresponding impact 1693 on context-level state information. One use for this facility is 1694 processing of the context_tokens generated by GSS_Delete_sec_ 1695 context(); GSS_Process_context_token() will not block pending 1696 network interactions for that purpose. Another use is to process 1697 tokens indicating remote-peer context establishment failures 1698 after the point where the local GSS-API implementation has 1699 already indicated GSS_COMPLETE status. 1701 2.2.5 GSS_Context_time call 1703 Input: 1705 o context_handle INTEGER, 1707 Outputs: 1709 o major_status INTEGER, 1711 o minor_status INTEGER, 1713 o lifetime_rec INTEGER - in seconds, or reserved value for 1714 INDEFINITE 1716 Return major_status codes: 1718 o GSS_COMPLETE indicates that the referenced context is valid, 1719 and will remain valid for the amount of time indicated in 1720 lifetime_rec. 1722 o GSS_CONTEXT_EXPIRED indicates that data items related to the 1723 referenced context have expired. 1725 40 Document Expiration: 28 February 1993 1726 Generic Security Service API: Internet-Draft: August 1992 1727 Common Authentication Technology WG: John Linn (DEC) 1729 o GSS_CREDENTIALS_EXPIRED indicates that the context is recog- 1730 nized, but that its associated credentials have expired. 1732 o GSS_NO_CONTEXT indicates that no valid context was recognized 1733 for the input context_handle provided. 1735 o GSS_FAILURE indicates that the requested operation failed for 1736 reasons unspecified at the GSS-API level. 1738 This call is used to determine the amount of time for which a 1739 currently established context will remain valid. 1741 2.3 Per-message calls 1743 This group of calls is used to perform per-message protection 1744 processing on an established security context. None of these 1745 calls block pending network interactions. These calls may be 1746 invoked by a context's initiator or by the context's target. 1747 The four members of this group should be considered as two 1748 pairs; the output from GSS_Sign() is properly input to GSS_ 1749 Verify(), and the output from GSS_Seal() is properly input to 1750 GSS_Unseal(). 1752 GSS_Sign() and GSS_Verify() support data origin authentication 1753 and data integrity services. When GSS_Sign() is invoked on 1754 an input message, it yields a per-message token containing 1755 data items which allow underlying mechanisms to provide the 1756 specified security services. The original message, along with 1757 the generated per-message token, is passed to the remote peer; 1758 these two data elements are processed by GSS_Verify(), which 1759 validates the message in conjunction with the separate token. 1761 GSS_Seal() and GSS_Unseal() support caller-requested confiden- 1762 tiality in addition to the data origin authentication and data 1763 integrity services offered by GSS_Sign() and GSS_Verify(). GSS_ 1764 Seal() outputs a single data element, encapsulating optionally- 1765 enciphered user data as well as associated token data items. 1766 The data element output from GSS_Seal() is passed to the remote 1767 peer and processed by GSS_Unseal() at that system. GSS_Unseal() 1769 Document Expiration: 28 February 1993 41 1770 Generic Security Service API: Internet-Draft: August 1992 1771 Common Authentication Technology WG: John Linn (DEC) 1773 combines decipherment (as required) with validation of data 1774 items related to authentication and integrity. 1776 2.3.1 GSS_Sign call 1778 Inputs: 1780 o context_handle INTEGER, 1782 o qop_req INTEGER,-0 specifies default QOP 1784 o message OCTET STRING 1786 Outputs: 1788 o major_status INTEGER, 1790 o minor_status INTEGER, 1792 o per_msg_token OCTET STRING 1794 Return major_status codes: 1796 o GSS_COMPLETE indicates that a signature, suitable for an 1797 established security context, was successfully applied and 1798 that the message and corresponding per_msg_token are ready 1799 for transmission. 1801 o GSS_CONTEXT_EXPIRED indicates that context-related data 1802 items have expired, so that the requested operation cannot be 1803 performed. 1805 o GSS_CREDENTIALS_EXPIRED indicates that the context is recog- 1806 nized, but that its associated credentials have expired, so 1807 that the requested operation cannot be performed. 1809 o GSS_NO_CONTEXT indicates that no valid context was recognized 1810 for the input context_handle provided. 1812 o GSS_FAILURE indicates that the context is recognized, but 1813 that the requested operation could not be performed for 1814 reasons unspecified at the GSS-API level. 1816 42 Document Expiration: 28 February 1993 1817 Generic Security Service API: Internet-Draft: August 1992 1818 Common Authentication Technology WG: John Linn (DEC) 1820 Using the security context referenced by context_handle, apply 1821 a signature to the input message (along with timestamps and/or 1822 other data included in support of mech_type-specific mechanisms) 1823 and return the result in per_msg_token. The qop_req parameter 1824 allows quality-of-protection control. The caller passes the 1825 message and the per_msg_token to the target. 1827 The GSS_Sign() function completes before the message and per_ 1828 msg_token is sent to the peer; successful application of GSS_ 1829 Sign() does not guarantee that a corresponding GSS_Verify() has 1830 been (or can necessarily be) performed successfully when the 1831 message arrives at the destination. 1833 2.3.2 GSS_Verify call 1835 Inputs: 1837 o context_handle INTEGER, 1839 o message OCTET STRING, 1841 o per_msg_token OCTET STRING 1843 Outputs: 1845 o qop_state INTEGER, 1847 o major_status INTEGER, 1849 o minor_status INTEGER, 1851 Return major_status codes: 1853 o GSS_COMPLETE indicates that the message was successfully 1854 verified. 1856 o GSS_DEFECTIVE_TOKEN indicates that consistency checks per- 1857 formed on the received per_msg_token failed, preventing 1858 further processing from being performed with that token. 1860 o GSS_BAD_SIG indicates that the received per_msg_token con- 1861 tains an incorrect signature for the message. 1863 Document Expiration: 28 February 1993 43 1864 Generic Security Service API: Internet-Draft: August 1992 1865 Common Authentication Technology WG: John Linn (DEC) 1867 o GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN 1868 values appear in conjunction with the optional per-message 1869 replay detection features described in Section 1.2.3; their 1870 semantics are described in that section. 1872 o GSS_CONTEXT_EXPIRED indicates that context-related data 1873 items have expired, so that the requested operation cannot be 1874 performed. 1876 o GSS_CREDENTIALS_EXPIRED indicates that the context is recog- 1877 nized, but that its associated credentials have expired, so 1878 that the requested operation cannot be performed. 1880 o GSS_NO_CONTEXT indicates that no valid context was recognized 1881 for the input context_handle provided. 1883 o GSS_FAILURE indicates that the context is recognized, but 1884 that the GSS_Verify() operation could not be performed for 1885 reasons unspecified at the GSS-API level. 1887 Using the security context referenced by context_handle, verify 1888 that the input per_msg_token contains an appropriate signature 1889 for the input message, and apply any active replay detection 1890 or sequencing features. Return an indication of the quality- 1891 of-protection applied to the processed message in the qop_state 1892 result. 1894 2.3.3 GSS_Seal call 1896 Inputs: 1898 o context_handle INTEGER, 1900 o conf_req_flag BOOLEAN, 1902 o qop_req INTEGER,-0 specifies default QOP 1904 o input_message OCTET STRING 1906 Outputs: 1908 o major_status INTEGER, 1910 44 Document Expiration: 28 February 1993 1911 Generic Security Service API: Internet-Draft: August 1992 1912 Common Authentication Technology WG: John Linn (DEC) 1914 o minor_status INTEGER, 1916 o conf_state BOOLEAN, 1918 o output_message OCTET STRING 1920 Return major_status codes: 1922 o GSS_COMPLETE indicates that the input_message was success- 1923 fully processed and that the output_message is ready for 1924 transmission. 1926 o GSS_CONTEXT_EXPIRED indicates that context-related data 1927 items have expired, so that the requested operation cannot be 1928 performed. 1930 o GSS_CREDENTIALS_EXPIRED indicates that the context is recog- 1931 nized, but that its associated credentials have expired, so 1932 that the requested operation cannot be performed. 1934 o GSS_NO_CONTEXT indicates that no valid context was recognized 1935 for the input context_handle provided. 1937 o GSS_FAILURE indicates that the context is recognized, but 1938 that the GSS_Seal() operation could not be performed for 1939 reasons unspecified at the GSS-API level. 1941 Performs the data origin authentication and data integrity 1942 functions of GSS_Sign(). If the input conf_req_flag is TRUE, 1943 requests that confidentiality be applied to the input_message. 1944 Confidentiality may not be supported in all mech_types or by all 1945 implementations; the returned conf_state flag indicates whether 1946 confidentiality was provided for the input_message. The qop_req 1947 parameter allows quality-of-protection control. 1949 In all cases, the GSS_Seal() call yields a single output_ 1950 message data element containing (optionally enciphered) user 1951 data as well as control information. 1953 Document Expiration: 28 February 1993 45 1954 Generic Security Service API: Internet-Draft: August 1992 1955 Common Authentication Technology WG: John Linn (DEC) 1957 2.3.4 GSS_Unseal call 1959 Inputs: 1961 o context_handle INTEGER, 1963 o input_message OCTET STRING 1965 Outputs: 1967 o conf_state BOOLEAN, 1969 o qop_state INTEGER, 1971 o major_status INTEGER, 1973 o minor_status INTEGER, 1975 o output_message OCTET STRING 1977 Return major_status codes: 1979 o GSS_COMPLETE indicates that the input_message was success- 1980 fully processed and that the resulting output_message is 1981 available. 1983 o GSS_DEFECTIVE_TOKEN indicates that consistency checks per- 1984 formed on the per_msg_token extracted from the input_message 1985 failed, preventing further processing from being performed. 1987 o GSS_BAD_SIG indicates that an incorrect signature was de- 1988 tected for the message. 1990 o GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN 1991 values appear in conjunction with the optional per-message 1992 replay detection features described in Section 1.2.3; their 1993 semantics are described in that section. 1995 o GSS_CONTEXT_EXPIRED indicates that context-related data 1996 items have expired, so that the requested operation cannot be 1997 performed. 1999 o GSS_CREDENTIALS_EXPIRED indicates that the context is recog- 2000 nized, but that its associated credentials have expired, so 2001 that the requested operation cannot be performed. 2003 46 Document Expiration: 28 February 1993 2004 Generic Security Service API: Internet-Draft: August 1992 2005 Common Authentication Technology WG: John Linn (DEC) 2007 o GSS_NO_CONTEXT indicates that no valid context was recognized 2008 for the input context_handle provided. 2010 o GSS_FAILURE indicates that the context is recognized, but 2011 that the GSS_Unseal() operation could not be performed for 2012 reasons unspecified at the GSS-API level. 2014 Processes a data element generated (and optionally enciphered) 2015 by GSS_Seal(), provided as input_message. The returned conf_ 2016 state value indicates whether confidentiality was applied to the 2017 input_message. If conf_state is TRUE, GSS_Unseal() deciphers 2018 the input_message. Returns an indication of the quality-of- 2019 protection applied to the processed message in the qop_state 2020 result. GSS_Seal() performs the data integrity and data ori- 2021 gin authentication checking functions of GSS_Verify() on the 2022 plaintext data. Plaintext data is returned in output_message. 2024 2.4 Support calls 2026 This group of calls provides support functions useful to GSS-API 2027 callers, independent of the state of established contexts. Their 2028 characterization with regard to blocking or non-blocking status 2029 in terms of network interactions is unspecified. 2031 2.4.1 GSS_Display_status call 2033 Inputs: 2035 o status_value INTEGER,-GSS-API major_status or minor_status 2036 return value 2038 o status_type INTEGER,-1 if major_status, 2 if minor_status 2040 o mech_type OBJECT IDENTIFIER-mech_type to be used for minor_ 2041 status translation 2043 Outputs: 2045 o major_status INTEGER, 2047 o minor_status INTEGER, 2049 Document Expiration: 28 February 1993 47 2050 Generic Security Service API: Internet-Draft: August 1992 2051 Common Authentication Technology WG: John Linn (DEC) 2053 o status_string_set SET OF OCTET STRING 2055 Return major_status codes: 2057 o GSS_COMPLETE indicates that a valid printable status repre- 2058 sentation (possibly representing more than one status event 2059 encoded within the status_value) is available in the returned 2060 status_string_set. 2062 o GSS_BAD_MECH indicates that translation in accordance with an 2063 unsupported mech_type was requested, so translation could not 2064 be performed. 2066 o GSS_BAD_STATUS indicates that the input status_value was 2067 invalid, or that the input status_type carried a value other 2068 than 1 or 2, so translation could not be performed. 2070 o GSS_FAILURE indicates that the requested operation could not 2071 be performed for reasons unspecified at the GSS-API level. 2073 Provides a means for callers to translate GSS-API-returned major 2074 and minor status codes into printable string representations. 2076 2.4.2 GSS_Indicate_mechs call 2078 Input: 2080 o (none) 2082 Outputs: 2084 o major_status INTEGER, 2086 o minor_status INTEGER, 2088 o mech_set SET OF OBJECT IDENTIFIER 2090 Return major_status codes: 2092 o GSS_COMPLETE indicates that a set of available mechanisms has 2093 been returned in mech_set. 2095 48 Document Expiration: 28 February 1993 2096 Generic Security Service API: Internet-Draft: August 1992 2097 Common Authentication Technology WG: John Linn (DEC) 2099 o GSS_FAILURE indicates that the requested operation could not 2100 be performed for reasons unspecified at the GSS-API level. 2102 Allows callers to determine the set of mechanism types avail- 2103 able on the local system. This call is intended for support of 2104 specialized callers who need to request non-default mech_type 2105 sets from GSS_Acquire_cred(), and should not be needed by other 2106 callers. 2108 2.4.3 GSS_Compare_name call 2110 Inputs: 2112 o name1 INTERNAL NAME, 2114 o name2 INTERNAL NAME, 2116 o name2_type OBJECT IDENTIFIER 2118 Outputs: 2120 o major_status INTEGER, 2122 o minor_status INTEGER, 2124 o name_equal BOOLEAN 2126 Return major_status codes: 2128 o GSS_COMPLETE indicates that name1 and name2 were comparable, 2129 and that the name_equal result indicates whether name1 and 2130 name2 were equal or unequal. 2132 o GSS_BAD_NAMETYPE indicates that one or both of name1 and 2133 name2 contained internal type specifiers uninterpretable 2134 by the supporting GSS-API implementation, or that the two 2135 names' types are different and incomparable, so the equality 2136 comparison could not be completed. 2138 o GSS_BAD_NAME indicates that one or both of the input names 2139 was ill-formed in terms of its internal type specifier, so 2140 the equality comparison could not be completed. 2142 Document Expiration: 28 February 1993 49 2143 Generic Security Service API: Internet-Draft: August 1992 2144 Common Authentication Technology WG: John Linn (DEC) 2146 o GSS_FAILURE indicates that the requested operation could not 2147 be performed for reasons unspecified at the GSS-API level. 2149 Allows callers to compare two internal name representations for 2150 equality. 2152 2.4.4 GSS_Display_name call 2154 Inputs: 2156 o name INTERNAL NAME 2158 Outputs: 2160 o major_status INTEGER, 2162 o minor_status INTEGER, 2164 o name_string OCTET STRING, 2166 o name_type OBJECT IDENTIFIER 2168 Return major_status codes: 2170 o GSS_COMPLETE indicates that a valid printable name represen- 2171 tation is available in the returned name_string. 2173 o GSS_BAD_NAMETYPE indicates that the provided name was of a 2174 type uninterpretable by the supporting GSS-API implementa- 2175 tion, so no printable representation could be generated. 2177 o GSS_BAD_NAME indicates that the contents of the provided name 2178 were inconsistent with the internally-indicated name type, so 2179 no printable representation could be generated. 2181 o GSS_FAILURE indicates that the requested operation could not 2182 be performed for reasons unspecified at the GSS-API level. 2184 Allows callers to translate an internal name representation into 2185 a printable form with associated namespace type descriptor. The 2186 syntax of the printable form is a local matter. 2188 50 Document Expiration: 28 February 1993 2189 Generic Security Service API: Internet-Draft: August 1992 2190 Common Authentication Technology WG: John Linn (DEC) 2192 2.4.5 GSS_Import_name call 2194 Inputs: 2196 o input_name_string OCTET STRING, 2198 o input_name_type OBJECT IDENTIFIER 2200 Outputs: 2202 o major_status INTEGER, 2204 o minor_status INTEGER, 2206 o output_name INTERNAL NAME 2208 Return major_status codes: 2210 o GSS_COMPLETE indicates that a valid name representation is 2211 output in output_name and described by the type value in 2212 output_name_type. 2214 o GSS_BAD_NAMETYPE indicates that the input_name_type is unsup- 2215 ported by the GSS-API implementation, so the import operation 2216 could not be completed. 2218 o GSS_BAD_NAME indicates that the provided input_name_string 2219 is ill-formed in terms of the input_name_type, so the import 2220 operation could not be completed. 2222 o GSS_FAILURE indicates that the requested operation could not 2223 be performed for reasons unspecified at the GSS-API level. 2225 Allows callers to provide a printable name representation, 2226 designate the type of namespace in conjunction with which it 2227 should be parsed, and convert that printable representation to 2228 an internal form suitable for input to other GSS-API routines. 2229 The syntax of the input_name is a local matter. 2231 Document Expiration: 28 February 1993 51 2232 Generic Security Service API: Internet-Draft: August 1992 2233 Common Authentication Technology WG: John Linn (DEC) 2235 2.4.6 GSS_Release_name call 2237 Inputs: 2239 o name INTERNAL NAME 2241 Outputs: 2243 o major_status INTEGER, 2245 o minor_status INTEGER 2247 Return major_status codes: 2249 o GSS_COMPLETE indicates that the storage associated with the 2250 input name was successfully released. 2252 o GSS_BAD_NAME indicates that the input name argument did not 2253 contain a valid name. 2255 o GSS_FAILURE indicates that the requested operation could not 2256 be performed for reasons unspecified at the GSS-API level. 2258 Allows callers to release the storage associated with an inter- 2259 nal name representation. 2261 2.4.7 GSS_Release_buffer call 2263 Inputs: 2265 o buffer OCTET STRING 2267 Outputs: 2269 o major_status INTEGER, 2271 o minor_status INTEGER 2273 Return major_status codes: 2275 o GSS_COMPLETE indicates that the storage associated with the 2276 input buffer was successfully released. 2278 52 Document Expiration: 28 February 1993 2279 Generic Security Service API: Internet-Draft: August 1992 2280 Common Authentication Technology WG: John Linn (DEC) 2282 o GSS_FAILURE indicates that the requested operation could not 2283 be performed for reasons unspecified at the GSS-API level. 2285 Allows callers to release the storage associated with an OCTET 2286 STRING buffer allocated by another GSS-API call. 2288 2.4.8 GSS_Release_oid_set call 2290 Inputs: 2292 o buffer SET OF OBJECT IDENTIFIER 2294 Outputs: 2296 o major_status INTEGER, 2298 o minor_status INTEGER 2300 Return major_status codes: 2302 o GSS_COMPLETE indicates that the storage associated with the 2303 input object identifier set was successfully released. 2305 o GSS_FAILURE indicates that the requested operation could not 2306 be performed for reasons unspecified at the GSS-API level. 2308 Allows callers to release the storage associated with an object 2309 identifier set object allocated by another GSS-API call. 2311 3 Mechanism-Specific Example Scenarios 2313 This section provides illustrative overviews of the use of var- 2314 ious candidate mechanism types to support the GSS-API. These 2315 discussions are intended primarily for readers familiar with 2316 specific security technologies, demonstrating how GSS-API 2317 functions can be used and implemented by candidate underly- 2318 ing mechanisms. They should not be regarded as constrictive 2319 to implementations or as defining the only means through which 2320 GSS-API functions can be realized with a particular underlying 2321 technology, and do not demonstrate all GSS-API features with 2322 each technology. 2324 Document Expiration: 28 February 1993 53 2325 Generic Security Service API: Internet-Draft: August 1992 2326 Common Authentication Technology WG: John Linn (DEC) 2328 3.1 Kerberos V5, single-TGT 2330 OS-specific login functions yield a TGT to the local realm Ker- 2331 beros server; TGT is placed in a credentials structure for the 2332 client. Client calls GSS_Acquire_cred() to acquire a cred_ 2333 handle in order to reference the credentials for use in estab- 2334 lishing security contexts. 2336 Client calls GSS_Init_sec_context(). If the requested service 2337 is located in a different realm, GSS_Init_sec_context() gets 2338 the necessary TGT/key pairs needed to traverse the path from 2339 local to target realm; these data are placed in the owner's TGT 2340 cache. After any needed remote realm resolution, GSS_Init_sec_ 2341 context() yields a service ticket to the requested service with 2342 a corresponding session key; these data are stored in conjunc- 2343 tion with the context. GSS-API code sends KRB_TGS_REQ request(s) 2344 and receives KRB_TGS_REP response(s) (in the successful case) or 2345 KRB_ERROR. 2347 Assuming success, GSS_Init_sec_context() builds a Kerberos- 2348 formatted KRB_AP_REQ message, and returns it in output_token. 2349 The client sends the output_token to the service. 2351 The service passes the received token as the input_token argu- 2352 ment to GSS_Accept_sec_context(), which verifies the authen- 2353 ticator, provides the service with the client's authenticated 2354 name, and returns an output_context_handle. 2356 Both parties now hold the session key associated with the ser- 2357 vice ticket, and can use this key in subsequent GSS_Sign(), 2358 GSS_Verify(), GSS_Seal(), and GSS_Unseal() operations. 2360 54 Document Expiration: 28 February 1993 2361 Generic Security Service API: Internet-Draft: August 1992 2362 Common Authentication Technology WG: John Linn (DEC) 2364 3.2 Kerberos V5, double-TGT 2366 TGT acquisition as above. 2368 Note: To avoid unnecessary frequent invocations of error paths 2369 when implementing the GSS-API atop Kerberos V5, it seems appro- 2370 priate to represent "single-TGT K-V5" and "double-TGT K-V5" with 2371 separate mech_types, and this discussion makes that assumption. 2373 Based on the (specified or defaulted) mech_type, GSS_Init_ 2374 sec_context() determines that the double-TGT protocol should 2375 be employed for the specified target. GSS_Init_sec_context() 2376 returns GSS_CONTINUE_NEEDED major_status[9], and its returned 2377 output_token contains a request to the service for the service's 2378 TGT. (If a service TGT with suitably long remaining lifetime 2379 already exists in a cache, it may be usable, obviating the 2380 need for this step.) The client passes the output_token to the 2381 service. 2383 The service passes the received token as the input_token ar- 2384 gument to GSS_Accept_sec_context(), which recognizes it as 2385 a request for TGT. (Note that current Kerberos V5 defines no 2386 intra-protocol mechanism to represent such a request.) GSS_ 2387 Accept_sec_context() returns GSS_CONTINUE_NEEDED major_status 2388 and provides the service's TGT in its output_token. The service 2389 sends the output_token to the client. 2391 The client passes the received token as the input_token argument 2392 to a continuation of GSS_Init_sec_context(). GSS_Init_sec_ 2393 context() caches the received service TGT and uses it as part 2394 of a service ticket request to the Kerberos authentication 2395 server, storing the returned service ticket and session key 2396 in conjunction with the context. GSS_Init_sec_context() builds 2398 ___________________ 2399 [9] This scenario illustrates a different use for the GSS_ 2400 CONTINUE_NEEDED status return facility than for support of 2401 mutual authentication; note that both uses can coexist as 2402 successive operations within a single context establishment 2404 operation. 2406 Document Expiration: 28 February 1993 55 2407 Generic Security Service API: Internet-Draft: August 1992 2408 Common Authentication Technology WG: John Linn (DEC) 2410 a Kerberos-formatted authenticator, and returns it in output_ 2411 token along with GSS_COMPLETE return major_status. The client 2412 sends the output_token to the service. 2414 Service passes the received token as the input_token argument 2415 to a continuation call to GSS_Accept_sec_context(). GSS_Accept_ 2416 sec_context() verifies the authenticator, provides the service 2417 with the client's authenticated name, and returns major_status 2418 GSS_COMPLETE. 2420 GSS_Sign(), GSS_Verify(), GSS_Seal(), and GSS_Unseal() as 2421 above. 2423 3.3 X.509 Authentication Framework 2425 This example illustrates use of the GSS-API in conjunction 2426 with public-key mechanisms, consistent with the X.509 Directory 2427 Authentication Framework. 2429 The GSS_Acquire_cred() call establishes a credentials struc- 2430 ture, making the client's private key accessible for use on 2431 behalf of the client. 2433 The client calls GSS_Init_sec_context(), which interrogates 2434 the Directory to acquire (and validate) a chain of public-key 2435 certificates, thereby collecting the public key of the service. 2436 The certificate validation operation determines that suitable 2437 signatures were applied by trusted authorities and that those 2438 certificates have not expired. GSS_Init_sec_context() generates 2439 a secret key for use in per-message protection operations on 2440 the context, and enciphers that secret key under the service's 2441 public key. 2443 The enciphered secret key, along with an authenticator quantity 2444 signed with the client's private key, is included in the out- 2445 put_token from GSS_Init_sec_context(). The output_token also 2446 carries a certification path, consisting of a certificate chain 2447 leading from the service to the client; a variant approach would 2449 56 Document Expiration: 28 February 1993 2450 Generic Security Service API: Internet-Draft: August 1992 2451 Common Authentication Technology WG: John Linn (DEC) 2453 defer this path resolution to be performed by the service in- 2454 stead of being asserted by the client. The client application 2455 sends the output_token to the service. 2457 The service passes the received token as the input_token ar- 2458 gument to GSS_Accept_sec_context(). GSS_Accept_sec_context() 2459 validates the certification path, and as a result determines a 2460 certified binding between the client's distinguished name and 2461 the client's public key. Given that public key, GSS_Accept_sec_ 2462 context() can process the input_token's authenticator quantity 2463 and verify that the client's private key was used to sign the 2464 input_token. At this point, the client is authenticated to the 2465 service. The service uses its private key to decipher the en- 2466 ciphered secret key provided to it for per-message protection 2467 operations on the context. 2469 The client calls GSS_Sign() or GSS_Seal() on a data mes- 2470 sage, which causes per-message authentication, integrity, and 2471 (optional) confidentiality facilities to be applied to that 2472 message. The service uses the context's shared secret key to 2473 perform corresponding GSS_Verify() and GSS_Unseal() calls. 2475 4 Related Activities 2477 In order to implement the GSS-API atop existing, emerging, and 2478 future security mechanisms: 2480 o object identifiers must be assigned to candidate GSS-API 2481 mechanisms and the name types which they support 2483 o concrete data element formats must be defined for candidate 2484 mechanisms (encapsulation within the mechanism-independent 2485 token format definition in Appendix B of this document is 2486 recommended to mechanism designers) 2488 Calling applications must implement formatting conventions which 2489 will enable them to distinguish GSS-API tokens from other data 2490 carried in their application protocols. 2492 Document Expiration: 28 February 1993 57 2493 Generic Security Service API: Internet-Draft: August 1992 2494 Common Authentication Technology WG: John Linn (DEC) 2496 Concrete language bindings are required for the programming en- 2497 vironments in which the GSS-API is to be employed; such bindings 2498 for the C language are available in an associated Internet- 2499 Draft. 2501 5 Acknowledgments 2503 This proposal is the result of a collaborative effort. Acknowl- 2504 edgments are due to the many members of the IETF Security Area 2505 Advisory Group (SAAG) and the Common Authentication Technology 2506 (CAT) Working Group for their contributions at meetings and by 2507 electronic mail. Acknowledgments are also due to Kannan Ala- 2508 gappan, Doug Barlow, Bill Brown, Cliff Kahn, Charlie Kaufman, 2509 Butler Lampson, Richard Pitkin, Joe Tardo, and John Wray of 2510 Digital Equipment Corporation, and John Carr, John Kohl, Jon 2511 Rochlis, Jeff Schiller, and Ted T'so of MIT and Project Athena. 2512 Joe Pato and Bill Sommerfeld of HP/Apollo, Walt Tuvell of OSF, 2513 and Bill Griffith and Mike Merritt of AT&T, provided inputs 2514 which helped to focus and clarify directions. Precursor work 2515 by Richard Pitkin, presented to meetings of the Trusted Systems 2516 Interoperability Group (TSIG), helped to demonstrate the value 2517 of a generic, mechanism-independent security service API. 2519 58 Document Expiration: 28 February 1993 2520 APPENDIX A 2522 PACS AND AUTHORIZATION SERVICES 2524 Consideration has been given to modifying the GSS-API service 2525 interface to recognize and manipulate Privilege Attribute Cer- 2526 tificates (PACs) as in ECMA 138, carrying authorization data as 2527 a side effect of establishing a security context, but no such 2528 modifications have been incorporated at this time. This appendix 2529 provides rationale for this decision and discusses compatibility 2530 alternatives between PACs and the GSS-API which do not require 2531 that PACs be made visible to GSS-API callers. 2533 Existing candidate mechanism types such as Kerberos and X.509 2534 do not incorporate PAC manipulation features, and exclusion of 2535 such mechanisms from the set of candidates equipped to fully 2536 support the GSS-API seems inappropriate. Inclusion (and GSS- 2537 API visibility) of a feature supported by only a limited number 2538 of mechanisms could encourage the development of ostensibly 2539 portable applications which would in fact have only limited 2540 portability. 2542 The status quo, in which PACs are not visible across the GSS-API 2543 interface, does not preclude implementations in which PACs are 2544 carried transparently, within the tokens defined and used for 2545 certain mech_types, and stored within peers' credentials and 2546 context-level data structures. While invisible to API callers, 2547 such PACs could be used by operating system or other local 2548 functions as inputs in the course of mediating access requests 2549 made by callers. This course of action allows dynamic selection 2550 of PAC contents, if such selection is administratively-directed 2551 rather than caller-directed. 2553 PACs and Authorization Services 59 2554 Generic Security Service API: Internet-Draft: August 1992 2555 Common Authentication Technology WG: John Linn (DEC) 2557 In a distributed computing environment, authentication must 2558 span different systems; the need for such authentication pro- 2559 vides motivation for GSS-API definition and usage. Heterogeneous 2560 systems in a network can intercommunicate, with globally au- 2561 thenticated names comprising the common bond between locally 2562 defined access control policies. Access control policies to 2563 which authentication provides inputs are often local, or spe- 2564 cific to particular operating systems or environments. If the 2565 GSS-API made particular authorization models visible across its 2566 service interface, its scope of application would become less 2567 general. The current GSS-API paradigm is consistent with the 2568 precedent set by Kerberos, neither defining the interpretation 2569 of authorization-related data nor enforcing access controls 2570 based on such data. 2572 The GSS-API is a general interface, whose callers may reside 2573 inside or outside any defined TCB or NTCB boundaries. Given this 2574 characteristic, it appears more realistic to provide facilities 2575 which provide "value-added" security services to its callers 2576 than to offer facilities which enforce restrictions on those 2577 callers. Authorization decisions must often be mediated below 2578 the GSS-API level in a local manner against (or in spite of) 2579 applications, and cannot be selectively invoked or omitted 2580 at those applications' discretion. Given that the GSS-API's 2581 placement prevents it from providing a comprehensive solution 2582 to the authorization issue, the value of a partial contribution 2583 specific to particular authorization models is debatable. 2585 60 PACs and Authorization Services 2586 APPENDIX B 2588 MECHANISM-INDEPENDENT TOKEN FORMAT 2590 This appendix specifies a mechanism-independent level of en- 2591 capsulating representation for the initial token of a GSS-API 2592 context establishment sequence, incorporating an identifier 2593 of the mechanism type to be used on that context. Use of this 2594 format (with ASN.1-encoded data elements represented in BER, 2595 constrained in the interests of parsing simplicity to the Dis- 2596 tinguished Encoding Rule (DER) BER subset defined in X.509, 2597 clause 8.7) is recommended to the designers of GSS-API imple- 2598 mentations based on various mechanisms, so that tokens can be 2599 interpreted unambiguously at GSS-API peers. There is no require- 2600 ment that the mechanism-specific innerContextToken, innerMs- 2601 gToken, and sealedUserData data elements be encoded in ASN.1 2602 BER. 2604 -- optional top-level token definitions to 2605 -- frame different mechanisms 2607 GSS-API DEFINITIONS ::= 2609 BEGIN 2611 MechType ::= OBJECT IDENTIFIER 2612 -- data structure definitions 2614 -- callers must be able to distinguish among 2615 -- InitialContextToken, SubsequentContextToken, 2616 -- PerMsgToken, and SealedMessage data elements 2617 -- based on the usage in which they occur 2619 Mechanism-Independent Token Format 61 2620 Generic Security Service API: Internet-Draft: August 1992 2621 Common Authentication Technology WG: John Linn (DEC) 2623 InitialContextToken ::= 2624 -- option indication (delegation, etc.) indicated within 2625 -- mechanism-specific token 2626 [APPLICATION 0] IMPLICIT SEQUENCE { 2627 thisMech MechType, 2628 innerContextToken ANY DEFINED BY thisMech 2629 -- contents mechanism-specific 2630 } 2632 SubsequentContextToken ::= innerContextToken ANY 2633 -- interpretation based on predecessor InitialContextToken 2635 PerMsgToken ::= 2636 -- as emitted by GSS_Sign and processed by GSS_Verify 2637 innerMsgToken ANY 2639 SealedMessage ::= 2640 -- as emitted by GSS_Seal and processed by GSS_Unseal 2641 -- includes internal, mechanism-defined indicator 2642 -- of whether or not encrypted 2643 sealedUserData ANY 2645 END 2647 62 Mechanism-Independent Token Format