idnits 2.17.1 draft-ietf-cat-fipsjjjgss-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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. == 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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 138 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 349: '...t ContextData OPTIONAL...' RFC 2119 keyword, line 355: '...dings OCTET STRING OPTIONAL,...' RFC 2119 keyword, line 356: '...tions Options OPTIONAL...' RFC 2119 keyword, line 372: '...t ContextData OPTIONAL...' RFC 2119 keyword, line 379: '...t ContextData OPTIONAL...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 71 has weird spacing: '...an instance ...' == Line 72 has weird spacing: '...orms to the...' == Line 73 has weird spacing: '...terface defin...' == Line 74 has weird spacing: '...n which makes...' == Line 78 has weird spacing: '... tokens defin...' == (133 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1995) is 10513 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) -- Looks like a reference, but probably isn't: 'APPLICATION 0' on line 304 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1508 (ref. '2') (Obsoleted by RFC 2078) ** Obsolete normative reference: RFC 1509 (ref. '3') (Obsoleted by RFC 2744) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Murphy 3 INTERNET-DRAFT D. Balenson 4 IETF Common Authentication Technology WG J. Galvin 5 TIS 6 July 1995 8 The FIPS PUB JJJ Entity Authentication GSS-API Mechanism 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, and 14 its Working Groups. Note that other groups may also distribute working 15 documents as Internet Drafts. 17 Internet Drafts are valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet Drafts as reference material or to cite 20 them other than as ``work in progress''. 22 To learn the current status of any Internet Draft, please check the 23 1id-abstracts.txt listing contained in one of the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This specification defines protocols, procedures, and conventions to be 31 employed by peers implementing the Generic Security Service Application 32 Program Interface, as specified in RFCs 1508 and 1509 [2] [3], (and as 33 amended by the Internet Draft defining GSS-API Version 2 [4]) when using 34 the FIPS PUB JJJ class of authentication mechanisms (as defined in FIPS 35 PUB JJJ [1]). 37 1. Acknowledgements 39 Some of the material in this document, particularly Sections 2 and 5, is 40 based on the Simple Public-Key GSS-API Mechanism (SPKM) specification 41 [5]. The authors of this document thank Warwick Ford, Paul Van Oorschot, 42 and Carlisle Adams of Bell-Northern Research, John Linn and Marc 43 Horowitz of OpenVision Technologies, and Joan Marshall for many fruitful 44 discussions. 46 2. Introduction 48 FIPS PUB JJJ, recently proposed as a Federal Information Processing 49 Standard (FIPS) [8], defines a class of mechanisms employing digital 50 signatures to provide either unilateral and mutual authentication using 51 public key cryptography. It is based primarily on a subset of ISO 52 Standard 9798 [6]. 54 The goal of the Generic Security Service Application Program Interface 55 (GSS-API) is stated in the abstract of RFC 1508 [2] as follows: 56 "This Generic Security Service Application Program Interface (GSS- 57 API) definition provides security services to callers in a generic 58 fashion, supportable with a range of underlying mechanisms and 59 technologies and hence allowing source-level portability of 60 applications to different environments. This specification defines 61 GSS-API services and primitives at a level independent of 62 underlying mechanism and programming language environment, and is 63 to be complemented by other, related specifications: 64 - documents defining specific parameter bindings for particular 65 language environments; 66 - documents defining token formats, protocols, and procedures to 67 be implemented in order to realize GSS-API services atop 68 particular security mechanisms." 70 Each mechanism in the FIPS PUB JJJ class of authentication mechanisms is 71 an instance of the latter type of document and is therefore termed a 72 "GSS-API Mechanism". If a FIPS PUB JJJ class mechanism conforms to the 73 interface defined by RFC 1508 [2], it can be used as a drop-in 74 replacement by any application which makes use of security services 75 through GSS-API calls (for example, any application which already uses 76 the Kerberos GSS-API for security). 78 The tokens defined in this document are intended to be used by 79 application programs according to the GSS API "operational paradigm" 80 (see RFC 1508 [2] for further details): 81 The operational paradigm in which GSS-API operates is as follows. 82 A typical GSS-API caller is itself a communications protocol [or 83 is an application program which uses a communications protocol], 84 calling on GSS-API in order to protect its communications with 85 authentication, integrity, and/or confidentiality security 86 services. A GSS-API caller accepts tokens provided to it by its 87 local GSS-API implementation [i.e., its GSS-API mechanism] and 88 transfers the tokens to a peer on a remote system; that peer 89 passes the received tokens to its local GSS-API implementation for 90 processing. 92 3. Related Work 94 FIPS PUB JJJ defines unilateral and mutual authentication mechanisms 95 based on ISO Standard 9798. There is an IETF effort presently ongoing 96 called Simple Public Key Mechanism [5] that defines unilateral and 97 mutual authentication mechanisms based on CCITT Standard X.509 [7]. The 98 two standards are extremely close in intent and technique. SPKM 99 includes more than just authentication; it also includes provisions for 100 confidentiality and integrity protection of the messages transmitted 101 through the established context. FIPS PUB JJJ provides authentication, 102 but no protection of the resultant context. The possibility that FIPS 103 PUB JJJ and the SPKM work could be combined should be pursued. 105 4. GSS-API Interface Calls 107 As FIPS PUB JJJ deals only with authentication, we define the 108 implementation of only the GSS-API context establishment calls for a 109 FIPS PUB JJJ class mechanism. We presume that some other negotiation, 110 either out of band, by the calling protocol, or by some as yet undefined 111 GSS-API negotiation mechanism, has determined that a FIPS PUB JJJ 112 mechanism will be used, or that a FIPS PUB JJJ mechanism is the local 113 default for the initiator and target. 115 4.1. GSS_Init_sec_context call 117 FIPS PUB JJJ defines authentication mechanisms for both unilateral and 118 mutual authentication. Unilateral authentication authenticates the 119 initiator to the target. There may be mechanisms that can support only 120 unilateral authentication or support only mutual authentication or that 121 can support both. As there is no reason to believe that any one 122 mechanism in the FIPS PUB JJJ class can do both types of authentication, 123 one duty of the GSS-API interface calls will be to negotiate the use of 124 mutual or unilateral authentication. 126 As FIPS PUB JJJ defines a class of authentication mechanisms, it is 127 possible that the initiator's and target's individual mechanisms may 128 have different sets of digital signature algorithms available. A 129 negotiation for algorithm type will proceed concurrently with the 130 negotiation of use of unilateral or mutual authentication. 132 4.1.1. First call to GSS_Init_sec_context 134 On the initial call to GSS_Init_sec_context, the initiator creates a 135 FIPS_SETUP token containing the set of representations for the digital 136 signature algorithms available locally, as well as flags indicating 137 whether mutual and/or unilateral authentication is available and whether 138 mutual or unilateral authentication is requested in the 139 GSS_Init_sec_context call. The services, i.e., delegation, sequencing, 140 etc., requested in the GSS_Init_sec_context call may optionally be 141 included in the token. (Different FIPS PUB JJJ class mechanisms may 142 have some or all of these services available; the negotiation for those 143 services is not specified here.) GSS_S_CONTINUE_NEEDED is returned as 144 the major_status code and FIPS_SETUP is returned as output_token. The 145 mech_type on entry must be FIPS_PUB_JJJ or null, and the returned value 146 must be FIPS_PUB_JJJ. 148 4.1.2. Second call to GSS_Init_sec_context 150 A second call to GSS_Init_sec_context must pass an input_token that is 151 either FIPS_ERROR, indicating an error, or FIPS_CHALN, containing the 152 final negotiated type of authentication, a subset of the initially 153 offered digital signature algorithm set indicating the algorithms 154 acceptable to the target and the FIPS PUB JJJ challenge from the target. 156 If the input_token is FIPS_ERROR, the major_status return code must be 157 GSS_S_FAILURE, with a minor_status code chosen to represent the error 158 indicated in the FIPS_ERROR token. No context is established. 160 If the input_token is FIPS_CHALN, then the initiator must pick one of 161 the set of digital signature algorithms indicated in the alg_subset 162 field to be used for the remainder of the authentication. The algorithm 163 choice is included in the output_token. 165 If unilateral authentication is indicated in the FIPS_CHALN, the 166 initiator must form a response to the challenge according to FIPS PUB 167 JJJ using the chosen digital signature algorithm and include the 168 response in the output_token. The output_token will be FIPS_REP_IT, the 169 major_status returned will be GSS_S_COMPLETE and a context should be 170 established. The values returned for deleg_state, mutual_state, 171 replay_det_state, sequence_state, and anon_state must take their values 172 from the FIPS_CHALN options field, if present. 174 If mutual authentication is indicated in the FIPS_CHALN, the initiator 175 must form a response to the challenge (using the chosen digital 176 signature algorithm) and a new challenge both according to FIPS PUB JJJ 177 and include the response and new challenge in the output_token. The 178 output_token will be FIPS_REPCHALN_IT and the major_status returned will 179 be GSS_S_CONTINUE_NEEDED. 181 4.1.3. Third call to GSS_Init_sec_context 183 A third call to GSS_Init_sec_context, necessary only if mutual 184 authentication is agreed upon, will pass an input_token that is either 185 FIPS_ERROR, indicating an error, or FIPS_REP_TI, containing the target's 186 response to the challenge from the initiator found in FIPS_REPCHALN_IT. 188 If the input_token is FIPS_ERROR, the major_status return code must be 189 GSS_S_FAILURE, as discussed above. 191 If the input_token is FIPS_REP_TI and the response to the challenge 192 fails verification, then the major_status returned should be either 193 GSS_S_BAD_SIG or GSS_S_FAILURE with an appropriate minor_status code, at 194 the implementor's option. Note that it is the decision and 195 responsibility of the caller to inform the other end of the connection 196 that authentication has failed. 198 If the input_token is FIPS_REP_TI and the response to the challenge is 199 verified, then the major_status returned must be GSS_S_COMPLETE and the 200 context should be established. The values returned for deleg_state, 201 mutual_state, replay_det_state, sequence_state, and anon_state must take 202 their values from the FIPS_REP_TI options field, if present. 204 The second and third calls to GSS_Init_sec_context can be distinguished 205 from the first by the fact that the input_token and input_context_handle 206 must be null in the first call and not null in the subsequent calls. 207 The second and third calls to GSS_Init_sec_context can be distinguished 208 by the token_ID's in the input_token, except in the case that the 209 input_token is FIPS_ERROR. FIPS_ERROR is a permissible parameter for 210 both the second and the third GSS_Init_sec_context calls. As the 211 processing in both cases is the same, this should not be a problem. 213 4.2. GSS_Accept_sec_context call 215 The GSS_Accept_sec_context call will always be called twice, whether 216 unilateral or mutual authentication is used in the context 217 establishment. 219 4.2.1. First call to GSS_Accept_sec_context 221 The call to GSS_Accept_sec_context will pass an input_token. If this is 222 the first call to GSS_Accept_sec_context, the token must be FIPS_SETUP. 223 The token contains the availability of unilateral and mutual 224 authentication at the initiator, as well as the caller's request for 225 unilateral or mutual authentication, and an indication of the set of 226 digital signature algorithms the initiator has available. 228 The target constructs the subset of the offered set of digital signature 229 algorithms that it has available. If this subset is empty, then the 230 initiator and target have no common digital signature algorithms. The 231 target must return a GSS_S_FAILURE major_status code and a FIPS_ERROR 232 token containing the error code 0001. No context will be established. 233 If this subset is not empty, then the subset must be included in the 234 alg_subset field of the FIPS_CHALN token. 236 If the initiator can do only unilateral authentication and the target 237 can do only mutual authentication or vice versa, then no context can be 238 established. The token returned will be FIPS_ERROR, with an error code 239 of 0002 and a major_status of GSS_S_FAILURE. If the initiator and 240 target can both do unilateral or both do mutual authentication, but not 241 both do both, then the common type must be specified in the returned 242 FIPS_CHALN token by setting the value of the mutual_tobeused field to 243 true (for mutual) or false (for unilateral). If both initiator and 244 target can both do both types of authentication, then the value of the 245 mutual_tobeused field in the returned FIPS_CHALN token must be set to 246 the value of the mutual_req field in the FIPS_SETUP token. In other 247 words, if the initiator and target can both do both types of 248 authentication, then the initiator's caller's request determines the 249 type. 251 If no error was determined, then a challenge must be formed (using the 252 chosen digital signature algorithm) according to FIPS PUB JJJ and 253 included in the output_token. The first call to GSS_Accept_sec_context 254 must return with a GSS_S_CONTINUE_NEEDED major_status code and 255 FIPS_CHALN as the output_token. 257 4.2.2. Second call to GSS_Accept_sec_context 259 The second call to GSS_Accept_sec_context can be distinguished by a 260 non-null input_context_handle and by the token_ID in the input_token. 261 The second call should pass an input_token containing either FIPS_ERROR 262 or a response token. If the authentication type was determined on the 263 first call to be unilateral authentication, then the response token must 264 be FIPS_REP_IT; if it was mutual, then the response token must be 265 FIPS_REPCHALN_IT. 267 The response token contains the response to the target's challenge. The 268 response must be verified according to FIPS PUB JJJ. If the 269 verification fails and mutual authentication was chosen, then a 270 FIPS_ERROR token must be formed with an error code of 0003. The 271 major_status returned should be either GSS_S_BAD_SIG or GSS_S_FAILURE 272 with an appropriate minor_status code, at the implementor's option. 273 Note that if unilateral authentication is chosen, receipt of a 274 FIPS_REP_IT token means that the other side of the connection has 275 completed context establishment. Therefore, it is the decision and 276 responsibility of the caller to inform the other side of the connection 277 that authentication has failed. 279 If the response to the challenge is verified, then the major_status 280 returned must be GSS_S_COMPLETE and the context must be established. If 281 the type of authentication is mutual, then the input_token was 282 FIPS_REPCHALN_IT and contains a challenge. A response to this challenge 283 must be formed according to FIPS PUB JJJ and included in a FIPS_REP_TI 284 output_token. In either case, the values returned for deleg_state, 285 mutual_state, replay_det_state, sequence_state, and anon_state must take 286 their values from the input_token, if present. 288 5. Tokens 290 Three classes of tokens are defined in this section: "Initiator" 291 tokens, emitted by calls to GSS_Init_sec_context() and consumed by calls 292 to GSS_Accept_sec_context(); "Target" tokens, emitted by calls to 293 GSS_Accept_sec_context() and consumed by calls to 294 GSS_Init_sec_context(); and "Error" tokens, potentially emitted by calls 295 to GSS_Init_sec_context() and GSS_Accept_sec_context(), and potentially 296 consumed by calls to GSS_Init_sec_context() and 297 GSS_Accept_sec_context(). The "Initiator" tokens are FIPS_SETUP, 298 FIPS_REP_IT, and FIPS_REPCHALN_IT. The "Target" tokens are FIPS_CHALN 299 and FIPS_REP_TI. The "Error" token is FIPS_ERROR. 301 Per RFC-1508, Appendix B, the initial context establishment token will 302 be enclosed within framing as follows: 304 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { 305 thisMech MechType 306 -- MechType is OBJECT IDENTIFIER 307 -- representing "FIPS PUB JJJ" 308 innerContextToken ANY DEFINED BY thisMech 309 -- contents mechanism-specific 310 } 312 The above GSS-API framing shall be applied to all tokens emitted by the 313 FIPS PUB JJJ GSS-API mechanism, FIPS_CHALN (the challenge from the 314 Target to the Initiator) FIPS_REP_IT (the response from the Initiator to 315 the Target for unilateral authentication), FIPS_REPCHALN_IT (the 316 response from the Initiator to the Target for mutual authentication), 317 FIPS_REP_TI (the response from the Target to the Initiator for mutual 318 authentication), and FIPS_ERROR, not just to the initial token 319 (FIPS_SETUP) in a context establishment sequence. While not required by 320 RFC-1508, this enables implementations to perform enhanced error- 321 checking. Furthermore, every innerContextToken will contain a token-id 322 followed by a context-id. 324 The innerContextToken field of context establishment tokens for the FIPS 325 PUB JJJ GSS-API mechanism will consist of a token (FIPS_SETUP 326 FIPS_CHALN, FIPS_REP_IT, FIPS_REPCHALN_IT,FIPS_REP_TI or FIPS_ERROR) 327 containing a token_ID field having the value 0100 (hex) for FIPS_SETUP 328 tokens, 0200 (hex) for FIPS_CHALN tokens, 0300 (hex) for FIPS_REP_IT, 329 0400 (hex) for FIPS_REPCHALN_IT tokens, 0500 (hex) for FIPS_REP_TI 330 tokens, and 0600 (hex) for FIPS_ERROR tokens. All innerContextToken's 331 are encoded using Abstract Syntax Notation One Basic Encoding Rules 332 (ASN.1 BER). 334 Each of the following tokens contains a token ID field. The FIPS tokens 335 themselves have an optional token ID field. But because this token is 336 an optional field, there is no guarantee that any particular mechanism 337 in the FIPS PUB JJJ class will have implemented that field. It is 338 therefore necessary to include such a field in the tokens here. 340 The FIPS tokens are defined in FIPS PUB JJJ, Appendix A. 342 FIPS_SETUP ::= SEQUENCE { 343 token_ID INTEGER, 344 context_ID RandomNumber, 345 alg_choices SEQUENCE OF AlgorithmIdentifier, 346 mutual_req BOOLEAN, 347 mutual_avail BOOLEAN, 348 unilateral_avail BOOLEAN, 349 context ContextData OPTIONAL 350 } 352 RandomNumber ::= INTEGER 354 ContextData ::= SEQUENCE { 355 chan_bindings OCTET STRING OPTIONAL, 356 options Options OPTIONAL 357 } 359 Options ::= BIT STRING { 360 deleg_req (0), 361 replay_req (1), 362 sequence_req (2), 363 anon_req (3), 364 lifetime_req (4) 365 } 367 FIPS_CHALN ::= SEQUENCE { 368 token_ID INTEGER, 369 context_ID RandomNumber, 370 alg_subset SEQUENCE OF AlgorithmIdentifier, 371 mutual_tobeused BOOLEAN, 372 context ContextData OPTIONAL 373 fips_token MessageBA 374 } 375 FIPS_REP_IT ::= SEQUENCE { 376 token_ID INTEGER, 377 context_ID RandomNumber, 378 alg_choice AlgorithmIdentifier, 379 context ContextData OPTIONAL 380 fips_token MessageABU 381 } 383 FIPS_REPCHALN_IT ::= SEQUENCE { 384 token_ID INTEGER, 385 context_ID RandomNumber, 386 alg_choice AlgorithmIdentifier, 387 context ContextData OPTIONAL 388 fips_token MessageABM 389 } 391 FIPS_REP_TI ::= SEQUENCE { 392 token_ID INTEGER, 393 context_ID RandomNumber, 394 alg_choice AlgorithmIdentifier, 395 context ContextData OPTIONAL 396 fips_token MessageBA2 397 } 399 FIPS_ERROR ::= SEQUENCE { 400 token_ID INTEGER, 401 context_ID RandomNumber, 402 error_type INTEGER 403 } 404 Where the value of error_type will be 405 0001 No compatible authentication algorithm found 406 0002 No compatible authentication type (mutual/unilateral) found 407 0003 Verification of challenge response has failed. 408 0004 Invalid token format 409 0005 Invalid format for fips_token field inside token 411 The following definition is taken from X.509 - The Directory: 412 Authentication Framework [7] 414 Algorithm Identifier ::= SEQUENCE { 415 algorithm OBJECT IDENTIFIER, 416 parameter ANY DEFINED BY algorithm OPTIONAL 417 } 419 6. Security Considerations 421 This document deals with the security issue of public-key based entity 422 authentication. 424 7. References 426 [1] Standard for Public Key Cryptographic Entity Authentication 427 Mechanisms (Draft), FIPS PUB JJJ, National Institute of Standards 428 and Technology, March 13, 1995. (Available online at 429 http://csrc.ncsl.nist.gov/fips as pkauth.txt and pkauth.ps.) 431 [2] Linn, J., Generic Security Service Application Program Interface, 432 RFC 1508, September 10, 1993. 434 [3] Wray, J., Generic Security Service API : C-bindings, RFC 1509, 435 September 10, 1993. 437 [4] Wray, J., Generic Security Service Application Program Interface, 438 Version 2, Internet Draft (work in progress), , March 1995. 441 [5] Adams, C., The Simple Public-Key GSS-API Mechanism (SPKM), Internet 442 Draft (work in progress), 444 [6] ISO/IEC 9798-1, Information Technology - Security Technologies - 445 Entity Authentication Mechanisms - Part 1: General model, 1991-09- 446 01. 448 [7] ITU-T Rec. X.509 | ISO/IEC 9594-8, Information Technology - Open 449 Systems Interconnection - The Directory: Authentication Framework, 450 Editor's DRAFT, February 14, 1993. 452 [8] Public Key Cryptography Entity Authentication Mechanisms, Federal 453 Register, Volume 60, Number 108, June 6, 1995, pp. 29749-29958. 455 8. Authors' Address 457 Sandra Murphy 458 Dave Balenson 459 Jim Galvin 461 Trusted Information Systems 462 3060 Washington Road 463 Glenwood, MD 21738 464 Table of Contents 466 Status of this Memo .............................................. 1 467 Abstract ......................................................... 1 468 1 Acknowledgements ................................................ 1 469 2 Introduction .................................................... 2 470 3 Related Work .................................................... 3 471 4 GSS-API Interface Calls ......................................... 3 472 4.1 GSS_Init_sec_context call ..................................... 3 473 4.1.1 First call to GSS_Init_sec_context .......................... 4 474 4.1.2 Second call to GSS_Init_sec_context ......................... 4 475 4.1.3 Third call to GSS_Init_sec_context .......................... 5 476 4.2 GSS_Accept_sec_context call ................................... 5 477 4.2.1 First call to GSS_Accept_sec_context ........................ 6 478 4.2.2 Second call to GSS_Accept_sec_context ....................... 6 479 5 Tokens .......................................................... 7 480 6 Security Considerations ......................................... 11 481 7 References ...................................................... 11 482 8 Authors' Address ................................................ 12