idnits 2.17.1 draft-ietf-cat-snego-08.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([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 292: '... mechTypes [0] MechTypeList OPTIONAL,...' RFC 2119 keyword, line 293: '... reqFlags [1] ContextFlags OPTIONAL,...' RFC 2119 keyword, line 294: '... mechToken [2] OCTET STRING OPTIONAL,...' RFC 2119 keyword, line 295: '... mechListMIC [3] OCTET STRING OPTIONAL...' RFC 2119 keyword, line 343: '... (2) } OPTIONAL,...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (4 March 1998) is 9550 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: '0' is mentioned on line 340, but not defined == Missing Reference: '3' is mentioned on line 346, but not defined ** Obsolete normative reference: RFC 2078 (ref. '1') (Obsoleted by RFC 2743) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Eric Baize, Denis Pinkas 3 IETF Common Authentication Technology WG Bull 4 4 March 1998 6 The Simple and Protected GSS-API Negotiation Mechanism 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Comments on this document should be sent to "cat-ietf@mit.edu", the 27 IETF Common Authentication Technology WG discussion list. Distribution 28 of this document is unlimited. 30 2. ABSTRACT 32 This draft document specifies a Security Negotiation Mechanism for the 33 Generic Security Service Application Program Interface (GSS-API) which 34 is described in [1]. 36 The GSS-API provides a generic interface which can be layered atop 37 different security mechanisms such that if communicating peers acquire 38 GSS-API credentials for the same security mechanism, then a security 39 context may be established between them (subject to policy). However, 40 GSS-API doesn't prescribe the method by which GSS-API peers can 41 establish whether they have a common security mechanism. 43 The Simple and Protected GSS-API Negotiation Mechanism defined here 44 is a pseudo-security mechanism, represented by the object identifier 45 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which 46 enables GSS-API peers to determine in-band whether their credentials 47 share common GSS-API security mechanism(s), and if so, to invoke 48 normal security context establishment for a selected common security 49 mechanism. This is most useful for applications that are based on 50 GSS-API implementations which support multiple security mechanisms. 52 This allows to negotiate different security mechanisms, different 53 options within a given security mechanism or different options from 54 several security mechanisms. 56 Once the common security mechanism is identified, the security 57 mechanism may also negotiate mechanism-specific options during its 58 context establishment. This will be inside the mechanism tokens, and 59 invisible to the SPNEGO protocol. 61 The simple and protected GSS-API mechanism negotiation is based on the 62 following negotiation model : the initiator proposes one security 63 mechanism or an ordered list of security mechanisms, the target either 64 accepts the proposed security mechanism, or chooses one from an 65 offered set, or rejects the proposed value(s). The target then informs 66 the initiator of its choice. 68 In its basic form this protocol requires an extra-round trip. Network 69 connection setup is a critical performance characteristic of any 70 network infrastructure and extra round trips over WAN links, packet 71 radio networks, etc. really make a difference. In order to avoid such 72 an extra round trip the initial security token of the preferred 73 mechanism for the initiator may be embedded in the initial token. 74 If the target preferred mechanism matches the initiator's preferred 75 mechanism, no additional round trips are incurred by using the 76 negotiation protocol. 78 The simple and protected GSS-API mechanism negotiation provides a 79 technique to protect the negotiation that must be used when the 80 underlying mechanism selected by the target is capable of integrity 81 protection. 83 When all the mechanisms proposed by the initiator support integrity 84 protection or when the selected mechanism supports integrity 85 protection, then the negotiation mechanism becomes protected since 86 this guarantees that the appropriate mechanism supported by both 87 peers has been selected. 89 The Simple and Protected GSS-API Negotiation Mechanism uses the 90 concepts developed in the GSS-API specification [1]. The negotiation 91 data is encapsulated in context-level tokens. Therefore, callers of 92 the GSS-API do not need to be aware of the existence of the 93 negotiation tokens but only of the new pseudo-security mechanism. 94 A failure in the negotiation phase causes a major status code to be 95 returned: GSS_S_BAD_MECH. 97 3. NEGOTIATION MODEL 99 3.1. Negotiation description 101 The model for security mechanism negotiation reuses a subset of the 102 concepts specified in [2]. 104 Each OID represents one GSS-API mechanism or one variant of it. 106 - When one security mechanism is proposed by the initiator, it 107 represents the only security mechanism supported or 108 selected (when the additional APIs defined in the Annex A 109 are used) by the initiator. 111 - When several security mechanisms are proposed by the initiator, 112 they represent a set of security mechanisms supported or selected 113 (when the additional APIs defined in the Annex A are used) by the 114 initiator. 116 The first negotiation token sent by the initiator contains an ordered 117 list of mechanisms, a set of options (e.g. deleg, replay, conf flags) 118 that should be supported by the selected mechanism and optionally the 119 initial security token for the desired mechanism of the initiator 120 (i.e. the first of the list). 122 The first negotiation token sent by the target contains the result of 123 the negotiation (accept_completed, accept_incomplete or reject) and, 124 in case of accept, the agreed security mechanism. It may also include 125 the response to the initial security token from the initiator, when 126 the first proposed mechanism of the initiator has been selected. When 127 the first mechanism is acceptable to the target,it should respond to 128 the initial security token for the desired mechanism of the initiator 129 when it is present. However, if this is not possible, the target can 130 simply ignore it and omit the responseToken from the first reply. 132 Implementations that can piggyback the initial token will be rewarded 133 by faster connection setup. 135 In case of a successful negotiation, the security mechanism represents 136 the value suitable for the target, and picked up from the list offered 137 by the initiator. The policy by which the target chooses a mechanism 138 is an implementation-specific local matter. In the absence of other 139 policy, the target should chose the first mechanism in the list for 140 which valid credentials are available. 142 Once a mechanism has been selected, the tokens specific to the 143 selected mechanism are carried within the negotiation tokens (in the 144 mechToken for the initiator and in the responseToken for the target). 146 3.2. Negotiation procedure 148 The negotiation procedure is summarised as follows: 150 (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but 151 requests (either explicitly, with the negotiation mechanism, or 152 through accepting a default, when the default is the negotiation 153 mechanism) that the Simple and Protected GSS-API Negotiation Mechanism 154 be used; 156 (b) the initiator GSS-API implementation emits a negotiation token 157 containing a list of supported security mechanisms for the credentials 158 used for this context establishment, and optionally an initial 159 security token for the first mechanism from that list (i.e. the 160 preferred mechanism), and indicates GSS_S_CONTINUE_NEEDED status; 162 (c) The GSS-API initiator sends the token to the target application; 164 (d) The GSS-API target deposits the token through invoking 165 GSS_Accept_sec_context. The target GSS-API implementation emits a 166 negotiation token containing which if any of the proposed mechanisms 167 it supports (or has selected). 169 If the mechanism selected by the target matches the preferred 170 mechanism identified by the initiator and the initiator provides a 171 mechToken, the negotiation token response may contain also an initial 172 security token from that mechanism. 174 If the preferred mechanism is accepted, GSS_Accept_sec_context() 175 indicates GSS_S_COMPLETE when unilateral or mutual authentication has 176 been performed and involves a single token in either direction. 178 If a proposed mechanism other than the preferred mechanism is 179 accepted, the negotiation token response may contain also an initial 180 security token from that mechanism (e.g. to transmit a certificate). 182 If a proposed mechanism other than the preferred mechanism is accepted, 183 or the preferred mechanism is accepted but involves multiple exchanges 184 (e.g. challenge-response authentication), then GSS_Accept_sec_context() 185 indicates GSS_S_CONTINUE_NEEDED status. 187 If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() 188 indicates GSS_S_BAD_MECH status. The security context initialisation 189 has failed. 191 (e) The GSS-API target returns the token to the initiator application; 193 (f) The GSS-API initiator deposits the token through invoking 194 GSS_Init_sec_context. 196 GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED, 197 GSS_S_COMPLETE or GSS_S_BAD_MECH status. 199 The GSS_S_BAD_MECH status is returned when the negotiation token 200 carries a reject result or when the negotiation token carries an 201 accept result and the mechanism selected by the target is not 202 included in the initial list sent by the initiator. 204 The GSS_S_BAD_SIG status is returned when the selected mechanism 205 supports a MIC token but the MIC computed over the list of 206 mechanisms sent by the initiator is missing or incorrect. 208 If the negotiation token carries a reject result, the 209 context establishment is impossible. For example, a rejection 210 will occur if the target doesn't support the initiator's proposed 211 mechanism type(s). Upon failure of the mechanism negotiation 212 procedure, the mech_type output parameter value is the 213 negotiation mechanism type. 215 The GSS_S_CONTINUE_NEEDED status is returned when the negotiation 216 token carries an accept result and further tokens must be 217 transferred in order to complete context establishment for the 218 selected mechanism. In that case GSS_Init_sec_context() returns 219 an initial context token as output_token (with the selected 220 mechanism's context token encapsulated within that output_token). 222 The initiator then sends the output_token to the target. The 223 security context initialisation is then continued according to 224 the standard GSS-API conventions for the selected mechanism, 225 where the tokens of the selected mechanism are encapsulated until 226 the GSS_S_COMPLETE is returned for both the initiator and the 227 target. When GSS_S_CONTINUE_NEEDED is returned, the mech_type 228 output parameter is not yet valid. 230 When GSS_S_COMPLETE is returned, the mech_type output parameter 231 indicates the selected mechanism. When the final negotiation token 232 does not contain a MIC, the initiator GSS-API implementation must 233 check the returned/selected mechanism is on the originally 234 submitted list of mechanisms and also verify that the 235 selected mechanism is not able to support a MIC. When the final 236 negotiation token contains a MIC over the initial mechanisms list 237 sent by the initiator, the MIC must be verified. 239 Note that the *_req_flag input parameters for context establishment 240 are relative to the selected mechanism, as are the *_state output 241 parameters. i.e., these parameters are not applicable to the 242 negotiation process per se. 244 The initiator GSS-API calling application may need to know when the 245 negotiation exchanges were protected or not. For this, when 246 GSS_S_COMPLETE is returned, it can simply test the integ_avail flag. 247 When this flag is set it indicates that the negotiation was protected. 249 On receipt of a negotiation token on the target side, a GSS-API 250 implementation that does not support negotiation would indicate the 251 GSS_S_BAD_MECH status as if a particular basic security mechanism had 252 been requested but was not supported. 254 When GSS_Acquire_cred is invoked with the negotiation mechanism as 255 desired_mechs, an implementation-specific default credential is used 256 to carry on the negotiation. A set of mechanisms as specified locally 257 by the system administrator is then available for negotiation. If there 258 is a desire for the caller to make its own choice, then an additional 259 API has to be used (see Appendix A). 261 4. DATA ELEMENTS 263 4.1. Mechanism Type 265 MechType::= OBJECT IDENTIFIER 266 mechType 267 Each security mechanism is as defined in [1]. 269 4.2. Negotiation Tokens 271 The syntax of the negotiation tokens follows the InitialContextToken 272 syntax defined in [1]. The security mechanism of the initial 273 negotiation token is identified by the Object Identifier 274 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). 276 4.2.1. Syntax 278 This section specifies the syntax of the corresponding 279 "innerContextToken" field for the first token and subsequent 280 negotiation tokens. During the mechanism negociation, 281 the "innerContextToken" field contains the ASN.1 structure 282 "NegociationToken" given below, encoded using the BER/DER encoding 283 conventions. 285 NegotiationToken ::= CHOICE { 286 negTokenInit [0] NegTokenInit, 287 negTokenTarg [1] NegTokenTarg } 289 MechTypeList ::= SEQUENCE OF MechType 291 NegTokenInit ::= SEQUENCE { 292 mechTypes [0] MechTypeList OPTIONAL, 293 reqFlags [1] ContextFlags OPTIONAL, 294 mechToken [2] OCTET STRING OPTIONAL, 295 mechListMIC [3] OCTET STRING OPTIONAL 296 } 298 ContextFlags ::= BIT STRING { 299 delegFlag (0), 300 mutualFlag (1), 301 replayFlag (2), 302 sequenceFlag (3), 303 anonFlag (4), 304 confFlag (5), 305 integFlag (6) 306 } 308 negTokenInit 309 Negotiation token sent by the initiator to the target, which 310 contains, for the first token sent, one or more security 311 mechanisms supported by the initiator (as indicated in the field 312 mechTypes) and the service options (reqFlags) that are requested 313 to establish the context. The context flags should be filled in 314 from the req_flags parameter of init_sec_context(). 316 The mechToken field is optional for the first token sent that 317 all target implementations would not have to support. However 318 for those targets that do support piggybacking the initial 319 mechToken, an optimistic negotiation response is possible. 321 Otherwise the mechToken is used to carry the tokens specific to 322 the mechanism selected. 324 The mechListMIC is an optional field. In the case that the chosen 325 mechanism supports integrity, the initiator may optionally include 326 a mechListMIC which is the result of a GetMIC of the MechTypes in 327 the initial NegTokenInit and return GSS_S_COMPLETE. 329 When the chosen mechanism uses an odd number of messages, the 330 final mechanism token will be sent from the initiator to the 331 acceptor. In this case, there is a tradeoff between using the 332 optimal number of messages, or using an additional message from 333 the acceptor to the initiator in order to give the initiator 334 assurance that no modification of the initiator's mechanism list 335 occurred. The implementation can choose which tradeoff to make 336 (see section 4.2.2 for further details for the processing of that 337 field). 339 NegTokenTarg ::= SEQUENCE { 340 negResult [0] ENUMERATED { 341 accept_completed (0), 342 accept_incomplete (1), 343 reject (2) } OPTIONAL, 344 supportedMech [1] MechType OPTIONAL, 345 responseToken [2] OCTET STRING OPTIONAL, 346 mechListMIC [3] OCTET STRING OPTIONAL 347 } 349 negTokenTarg 350 Negotiation token returned by the target to the initiator which 351 contains, for the first token returned, a global negotiation 352 result and the security mechanism selected (if any). 354 negResult 355 The result accept_completed indicates that a context has been 356 successfully established, while the result accept_incomplete 357 indicates that additional token exchanges are needed. 359 Note: For the case where (a) a single-token context setup 360 is used and (b) the preferred mechanism does not support 361 the integrity facility which would cause a mechListMIC to be 362 generated and enclosed, this feature allows to make a 363 difference between a mechToken sent by the initiator 364 but not processed by the target (accept_incomplete) and 365 a mechToken sent by the initiator and processed by 366 the target (accept_completed). 368 For those targets that support piggybacking the initial 369 mechToken, an optimistic negotiation response is possible 370 and includes in that case a responseToken which may continue 371 the authentication exchange (e.g. when mutual authentication has 372 been requested or when unilateral authentication requires several 373 round trips). Otherwise the responseToken is used to carry the 374 tokens specific to the mechanism selected. 376 For subsequent tokens (if any) returned by the target, negResult, 377 and supportedMech are not present. 379 For the last token returned by the target, the mechListMIC, when 380 present, is a MIC computed over the MechTypes using the selected 381 mechanism. 383 negResult 384 Result of the negotiation exchange, specified by the target. 386 This can be either : 388 accept_completed 389 The target accepts the preferred security mechanism, 390 and the context is established for the target or, 392 accept_incomplete 393 The target accepts one of the proposed security 394 mechanisms and further exchanges are necessary, or, 396 reject 397 The target rejects all the proposed security 398 mechanisms. 400 supportedMech 401 This field has to be present when negResult is "accept_completed" 402 or "accept_incomplete". It is a choice from the mechanisms offered 403 by the initiator. 405 responseToken 406 This field may be used either to transmit the response to the 407 mechToken when sent by the initiator and when the first 408 mechanism from the list has been selected by the target or 409 to carry the tokens specific to the selected security mechanism. 411 mechListMIC 412 If the selected mechanism is capable of integrity protection, 413 this field must be present in the last message of the negotiation, 414 (i.e., when the underlying mechanism returns a non-empty token 415 and a major status of GSS_S_COMPLETE); it contains the result of a 416 GetMIC of the MechTypes field in the initial NegTokenInit. 417 It allows to verify that the list initially sent by the initiator 418 has been received unmodified by the target. 420 4.2.2. Processing of mechListMIC. 422 If the mechanism selected by the negotiation does not support 423 integrity, then no mechListMIC is included, otherwise a 424 mechListMIC must be used and validated as indicated below. 426 If the mechanism supports integrity and uses an even number of 427 messages, then the target must compute a MIC as described above, 428 and send this in the final NegTokenTarg along with the final 429 mechToken. The initiator when receiving the last token must 430 require that the mechListMIC field be present and valid. In the 431 absence of a valid mechListMIC, the negotiation must fail as if 432 the last context establishment token was invalid. 434 In the case that the chosen mechanism supports integrity and uses 435 an odd number of messages, the final mechanism token will be sent 436 from the initiator to the target. In this case, there is a 437 tradeoff between using the optimal number of messages, or using an 438 additional message from the target to the initiator in order to 439 give the initiator assurance that no modification of the 440 initiator's mechanism list occurred. The implementation can choose 441 which tradeoff to make. 443 When generating the final NegTokenInit message, the NegTokenInit 444 may optionally include a mechListMIC which is the result of a 445 GetMIC of the MechTypes in the initial NegTokenInit and return 446 GSS_S_COMPLETE. The target must check the presence of the MIC 447 computed over the mechList sent in the initial NegTokenInit. 448 Three cases may then be considered: 450 1) If the mechListMIC is present and correct the context is 451 established by the target. 453 2) If the mechList is present but corrupted, then the context 454 establishment must fail. 456 3) If the mechListMIC is not included in the final 457 NegTokenInit, then GSS_S_CONTINUE_NEEDED must be returned 458 to the target. The MIC must then be included in the 459 NegTokenTarg as described above, and the NegTokenTarg must 460 be sent back to the initiator, which must verify that the 461 mechListMIC field is present and valid. 463 Note : If the MIC was originally sent by the initiator, but 464 thenafter deleted by an attacker, the target will send 465 back a token according to the description above, but 466 the initiator will be unable to process that returned 467 token and the context establishment must then fail. 469 5. EXAMPLES : SECURITY MECHANISM NEGOTIATION 471 Here are some examples of security mechanism negotiation between an 472 initiator (I) and a target (T). 474 5.1. Initial steps 476 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2). 478 (I) invokes GSS_Init_sec_context() with : 480 Input 481 mech_type = OID for negotiation mechanism or NULL, if the 482 negotiation mechanism is the default mechanism. 484 Output 485 major_status = GSS_S_CONTINUE_NEEDED 486 output_token = negTokenInit 488 The negotiation token (negTokenInit) contains two security mechanisms 489 with : 490 mechType = GSS-MECH1 or 491 mechType = GSS-MECH2 493 (I) sends to (T) the negotiation token. 495 5.2 Successful negotiation steps 497 (T) supports GSS-MECH2 498 (T) receives the negotiation token (negTokenInit) from (I) 499 (T) invokes GSS_Accept_sec_context() with : 501 Input 502 input_token = negTokenInit 504 Output 505 major_status = GSS_S_CONTINUE_NEEDED 506 output_token = negTokenTarg 508 The negotiation token (negTokenTarg) contains : 509 negResult = accept (the negotiation result) 510 supportedMech : mechType = GSS-MECH2 512 (T) returns the negotiation token (negTokenTarg) to (I) 513 (I) invokes GSS_Init_sec_context() with : 515 Input 516 input_token = negTokenTarg 518 Output 519 major_status = GSS_S_COMPLETE 520 output_token = initialContextToken (initial context token 521 for GSS-MECH2) 522 mech_type = GSS-MECH2 524 The subsequent steps are security mechanism specific, and work as 525 specified in [1]. The output tokens from the security mechanism are 526 encapsulated in a NegTokenTarg message (with the supportedMech field 527 omitted, and the mechListMIC included with the last token). 529 5.3. Failed negotiation steps 531 (T) supports GSS-MECH3. 532 (T) receives the negotiation token (negTokenInit) from (I) 533 (T) invokes GSS_Accept_sec_context() with : 535 Input 536 input_token = negTokenInit 538 Output 539 major_status = GSS_S_BAD_MECH 540 output_token = negTokenTarg 542 The negotiation token (negTokenTarg) contains : 544 negResult = reject (the negotiation result) 546 (T) returns the negotiation token (negTokenTarg) to (I) 547 (I) invokes GSS_Init_sec_context() with : 549 Input 550 input_token = negTokenTarg 552 Output 553 major_status = GSS_S_BAD_MECH 555 The security context establishment has failed. 557 5.4 Successful Negotiation with preferred mechanism info 559 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2). 561 (I) invokes GSS_Init_sec_context() with : 563 Input 564 mech_type = OID for negotiation mechanism or NULL, if the 565 negotiation mechanism is the default mechanism. 567 Output 568 major_status = GSS_S_CONTINUE_NEEDED 569 output_token = negTokenInit 571 The negotiation token (negTokenInit) contains two security mechanisms 572 with : 573 mechType = GSS-MECH1 or 574 mechType = GSS-MECH2 576 mechToken = output_token from GSS_Init_sec_context 577 ( first mechType) as described in [1] 579 (I) sends to (T) the negotiation token. 581 (T) supports GSS-MECH1. 582 (T) receives the negotiation token (negTokenInit) from (I) 583 (T) invokes GSS_Accept_sec_context() with : 585 Input 586 input_token = negTokenInit 588 Output 589 major_status = GSS_S_CONTINUE_NEEDED 590 output_token = negTokenTarg 592 The negotiation token (negTokenTarg) contains : 593 negResult = accept (the negotiation result) 594 supportedMech : mechType = GSS-MECH1 596 mechToken = output_token from 597 GSS_Accept_sec_context(mechToken ) 599 (T) returns the negotiation token (negTokenTarg) to (I) 600 (I) invokes GSS_Init_sec_context() with : 602 Input 603 input_token = negTokenTarg 605 Output 606 major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed 607 output_token = ContextToken (initial or subsequent context token 608 for GSS-MECH1) 609 mech_type = GSS-MECH1 611 Specific implementations of the protocol can support the optimistic 612 negotiation by completing the security context establishment using the 613 agreed upon mechanism as described in [1]. As described above in 614 section 5.2, the output tokens from the security mechanisms are 615 encapsulated in a NegTokenTarg message (with the negResult and 616 supportedMech fields omitted, and the mechListMIC included with the 617 last token). 619 6. ACKNOWLEDGMENTS 621 Acknowledgments are due to Piers McMahon and Tom Parker of ICL, 622 Stephen Farrell of SSE, Doug Rosenthal of EINet, John Linn of 623 RSA Laboratories, and Marc Horowitz of Cygnus Solutions for reviewing 624 earlier versions of this document and for providing useful inputs. 625 Acknowledgments are also due to Peter Brundrett of Microsoft for 626 his proposal for an optimistic negotiation, and for Bill Sommerfeld 627 of Hewlett-Packard for his proposal for protecting the negotiation. 629 7. SECURITY CONSIDERATIONS 631 When the mechanism selected by the target from the list supplied by 632 the initiator supports integrity protection, then the negotiation is 633 protected. 635 When one of the mechanisms proposed by the initiator does not support 636 integrity protection, then the negotiation is exposed to all threats 637 a non secured service is exposed. In particular, an active attacker 638 can force to use a security mechanism which is not the common 639 preferred one (when multiple security mechanisms are shared between 640 peers) but which is acceptable anyway to the target. 642 In any case, the communicating peers may be exposed to the denial of 643 service threat. 645 APPENDIX A 647 GSS-API NEGOTIATION SUPPORT API 649 In order to provide to a GSS-API caller (either the initiator or the 650 target or both) the ability to choose among the set of supported 651 mechanisms a reduced set of mechanisms for negotiation, two 652 additional APIs are defined: 654 GSS_Get_neg_mechs() indicates the set of security mechanisms available 655 on the local system to the caller for negotiation. 657 GSS_Set_neg_mechs() specifies the set of security mechanisms to be 658 used on the local system by the caller for negotiation. 660 A.1. GSS_Set_neg_mechs call 662 Input: 663 cred_handle CREDENTIAL HANDLE 664 - NULL specifies default credentials 665 mech_set SET OF OBJECT IDENTIFIER 667 Outputs: 668 major_status INTEGER, 669 minor_status INTEGER, 671 Return major_status codes : 672 GSS_S_COMPLETE indicates that the set of security mechanisms 673 available for negotiation has been set to mech_set. 674 GSS_S_FAILURE indicates that the requested operation could not be 675 performed for reasons unspecified at the GSS-API level. 677 Allows callers to specify the set of security mechanisms that 678 may be negotiated with the credential identified by cred_handle. 679 This call is intended for support of specialised callers who need 680 to restrict the set of negotiable security mechanisms from the set 681 of all security mechanisms available to the caller (based on 682 available credentials). Note that if more than one mechanism is 683 specified in mech_set, the order in which those mechanisms are 684 specified implies a relative mechanism preference for the target. 686 A.2. GSS_Get_neg_mechs call 688 Input: 689 cred_handle CREDENTIAL HANDLE 690 - NULL specifies default credentials 692 Outputs: 693 major_status INTEGER, 694 minor_status INTEGER, 695 mech_set SET OF OBJECT IDENTIFIER 697 Return major_status codes : 698 GSS_S_COMPLETE indicates that the set of security mechanisms 699 available for negotiation has been returned in 700 mech_option_set. 701 GSS_S_FAILURE indicates that the requested operation could not 702 be performed for reasons unspecified at the GSS-API level. 704 Allows callers to determine the set of security mechanisms available 705 for negotiation with the credential identified by cred_handle. This 706 call is intended for support of specialised callers who need to 707 reduce the set of negotiable security mechanisms from the set of 708 supported security mechanisms available to the caller (based on 709 available credentials). 711 Note: The GSS_Indicate_mechs() function indicates the full set of 712 mechanism types available on the local system. Since this call has no 713 input parameter, the returned set is not necessarily available for all 714 credentials. 716 REFERENCES 718 [1] Linn, J., "Generic Security Service Application Program 719 Interface", RFC 2078, OpenVision, January 1997. Available on 720 ftp://ds.internic.net/rfc/rfc2078.txt 722 [2] Standard ECMA-206, "Association Context Management including 723 Security Context Management", December 1993. Available on 724 http://www.ecma.ch 726 AUTHORS'S ADDRESSES 728 Eric Baize Internet email: E.Baize@bull.com 729 Bull HN - MA02/211S Phone: +1 508 294 61 37 730 Technology Park Fax: +1 508 294 61 09 731 Billerica, MA 01821 - USA 733 Denis Pinkas Internet email: D.Pinkas@bull.net 734 Bull Phone: +33 1 30 80 34 87 735 Rue Jean-Jaures Fax: +33 1 30 80 33 21 736 BP 68 737 78340 Les Clayes-sous-Bois - FRANCE