doc/standardisation/rfc2478.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         E. Baize
   8 Request for Comments: 2478                                   D. Pinkas
   9 Category: Standards Track                                         Bull
  10                                                          December 1998
  11
  12
  13          The Simple and Protected GSS-API Negotiation Mechanism
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  26
  27 1.  ABSTRACT
  28
  29    This document specifies a Security Negotiation Mechanism for the
  30    Generic Security Service Application Program Interface (GSS-API)
  31    which is described in [1].
  32
  33    The GSS-API provides a generic interface which can be layered atop
  34    different security mechanisms such that if communicating peers
  35    acquire GSS-API credentials for the same security mechanism, then a
  36    security context may be established between them (subject to policy).
  37    However, GSS-API doesn't prescribe the method by which GSS-API peers
  38    can establish whether they have a common security mechanism.
  39
  40    The Simple and Protected GSS-API Negotiation Mechanism defined here
  41    is a pseudo-security mechanism, represented by the object identifier
  42    iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which
  43    enables GSS-API peers to determine in-band whether their credentials
  44    share common GSS-API security mechanism(s), and if so, to invoke
  45    normal security context establishment for a selected common security
  46    mechanism. This is most useful for applications that are based on
  47    GSS-API implementations which support multiple security mechanisms.
  48
  49    This allows to negotiate different security mechanisms, different
  50    options within a given security mechanism or different options from
  51    several security mechanisms.
  52
  53
  54
  55
  56
  57
  58 Baize & Pinkas              Standards Track                     [Page 1]
  59 \f
  60 RFC 2478             GSS-API Negotiation Mechanism         December 1998
  61
  62
  63    Once the common security mechanism is identified, the security
  64    mechanism may also negotiate mechanism-specific options during its
  65    context establishment. This will be inside the mechanism tokens, and
  66    invisible to the SPNEGO protocol.
  67
  68    The simple and protected GSS-API mechanism negotiation is based on
  69    the following negotiation model : the initiator proposes one security
  70    mechanism or an ordered list of security mechanisms, the target
  71    either accepts the proposed security mechanism, or chooses one from
  72    an offered set, or rejects the proposed value(s). The target then
  73    informs the initiator of its choice.
  74
  75    In its basic form this protocol requires an extra-round trip. Network
  76    connection setup is a critical performance characteristic of any
  77    network infrastructure and extra round trips over WAN links, packet
  78    radio networks, etc. really make a difference. In order to avoid such
  79    an extra round trip the initial security token of the preferred
  80    mechanism for the initiator may be embedded in the initial token. If
  81    the target preferred mechanism matches the initiator's preferred
  82    mechanism, no additional round trips are incurred by using the
  83    negotiation protocol.
  84
  85    The simple and protected GSS-API mechanism negotiation provides a
  86    technique to protect the negotiation that must be used when the
  87    underlying mechanism selected by the target is capable of integrity
  88    protection.
  89
  90    When all the mechanisms proposed by the initiator support integrity
  91    protection or when the selected mechanism supports integrity
  92    protection, then the negotiation mechanism becomes protected since
  93    this guarantees that the appropriate mechanism supported by both
  94    peers has been selected.
  95
  96    The Simple and Protected GSS-API Negotiation Mechanism uses the
  97    concepts developed in the GSS-API specification [1]. The negotiation
  98    data is encapsulated in context-level tokens. Therefore, callers of
  99    the GSS-API do not need to be aware of the existence of the
 100    negotiation tokens but only of the new pseudo-security mechanism. A
 101    failure in the negotiation phase causes a major status code to be
 102    returned: GSS_S_BAD_MECH.
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Baize & Pinkas              Standards Track                     [Page 2]
 115 \f
 116 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 117
 118
 119 2.  NEGOTIATION MODEL
 120
 121 2.1.  Negotiation description
 122
 123    The model for security mechanism negotiation reuses a subset of the
 124    concepts specified in [2].
 125
 126    Each OID represents one GSS-API mechanism or one variant of it.
 127
 128     -  When one security mechanism is proposed by the initiator, it
 129        represents the only security mechanism supported or selected
 130        (when the additional APIs defined in the Annex A are used) by the
 131        initiator.
 132
 133     -  When several security mechanisms are proposed by the initiator,
 134        they represent a set of security mechanisms supported or selected
 135        (when the additional APIs defined in the Annex A are used) by the
 136        initiator.
 137
 138    The first negotiation token sent by the initiator contains an ordered
 139    list of mechanisms, a set of options (e.g. deleg, replay, conf flags)
 140    that should be supported by the selected mechanism and optionally the
 141    initial security token for the desired mechanism of the initiator
 142    (i.e. the first of the list).
 143
 144    The first negotiation token sent by the target contains the result of
 145    the negotiation (accept_completed, accept_incomplete or reject) and,
 146    in case of accept, the agreed security mechanism. It may also include
 147    the response to the initial security token from the initiator, when
 148    the first proposed mechanism of the initiator has been selected. When
 149    the first mechanism is acceptable to the target,it should respond to
 150    the initial security token for the desired mechanism of the initiator
 151    when it is present. However, if this is not possible, the target can
 152    simply ignore it and omit the responseToken from the first reply.
 153
 154    Implementations that can piggyback the initial token will be rewarded
 155    by faster connection setup.
 156
 157    In case of a successful negotiation, the security mechanism
 158    represents the value suitable for the target, and picked up from the
 159    list offered by the initiator.  The policy by which the target
 160    chooses a mechanism is an implementation-specific local matter.  In
 161    the absence of other policy, the target should chose the first
 162    mechanism in the list for which valid credentials are available.
 163
 164    Once a mechanism has been selected, the tokens specific to the
 165    selected mechanism are carried within the negotiation tokens (in the
 166    mechToken for the initiator and in the responseToken for the target).
 167
 168
 169
 170 Baize & Pinkas              Standards Track                     [Page 3]
 171 \f
 172 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 173
 174
 175 2.2.  Negotiation procedure
 176
 177    The negotiation procedure is summarised as follows:
 178
 179    (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but
 180        requests (either explicitly, with the negotiation mechanism, or
 181        through accepting a default, when the default is the negotiation
 182        mechanism) that the Simple and Protected GSS-API Negotiation
 183        Mechanism be used;
 184
 185    (b) the initiator GSS-API implementation emits a negotiation token
 186        containing a list of supported security mechanisms for the
 187        credentials used for this context establishment, and optionally
 188        an initial security token for the first mechanism from that list
 189        (i.e. the preferred mechanism), and indicates
 190        GSS_S_CONTINUE_NEEDED status;
 191
 192    (c) The GSS-API initiator sends the token to the target application;
 193
 194    (d) The GSS-API target deposits the token through invoking
 195        GSS_Accept_sec_context. The target GSS-API implementation emits a
 196        negotiation token containing which if any of the proposed
 197        mechanisms it supports (or has selected).
 198
 199    If the mechanism selected by the target matches the preferred
 200    mechanism identified by the initiator and the initiator provides a
 201    mechToken, the negotiation token response may contain also an initial
 202    security token from that mechanism.
 203
 204    If the preferred mechanism is accepted, GSS_Accept_sec_context()
 205    indicates GSS_S_COMPLETE when unilateral or mutual authentication has
 206    been performed and involves a single token in either direction.
 207
 208    If a proposed mechanism is accepted, and it was not the preferred
 209    mechanism, or if the first negotiation token sent by the initiator
 210    did not included a mechToken, then the negotiation token response
 211    sent by the target may contain also a response token from that
 212    mechanism which transmits mechanism-specific information (e.g. to
 213    transmit a certificate). The initiator may ignore such an initial
 214    token if it is not prepared to process it.
 215
 216    If a proposed mechanism other than the preferred mechanism is
 217    accepted, or the preferred mechanism is accepted but involves
 218    multiple exchanges (e.g. challenge-response authentication), then
 219    GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status.
 220
 221
 222
 223
 224
 225
 226 Baize & Pinkas              Standards Track                     [Page 4]
 227 \f
 228 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 229
 230
 231    If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()
 232    indicates GSS_S_BAD_MECH status. The security context initialisation
 233    has failed.
 234
 235    (e) The GSS-API target returns the token to the initiator
 236        application;
 237
 238    (f) The GSS-API initiator deposits the token through invoking
 239        GSS_Init_sec_context.
 240
 241    GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED,
 242    GSS_S_COMPLETE or GSS_S_BAD_MECH status.
 243
 244       The GSS_S_BAD_MECH status is returned when the negotiation token
 245       carries a reject result or when the negotiation token carries an
 246       accept result and the mechanism selected by the target is not
 247       included in the initial list sent by the initiator.
 248
 249       The GSS_S_BAD_MIC status is returned when the selected mechanism
 250       supports a MIC token but the MIC computed over the list of
 251       mechanisms sent by the initiator is missing or incorrect.
 252
 253       If the negotiation token carries a reject result, the context
 254       establishment is impossible. For example, a rejection will occur
 255       if the target doesn't support the initiator's proposed mechanism
 256       type(s). Upon failure of the mechanism negotiation procedure, the
 257       mech_type output parameter value is the negotiation mechanism
 258       type.
 259
 260       The GSS_S_CONTINUE_NEEDED status is returned when the negotiation
 261       token carries an accept result and further tokens must be
 262       transferred in order to complete context establishment for the
 263       selected mechanism. In that case GSS_Init_sec_context() returns an
 264       initial context token as output_token (with the selected
 265       mechanism's context token encapsulated within that output_token).
 266
 267       The initiator then sends the output_token to the target. The
 268       security context initialisation is then continued according to the
 269       standard GSS-API conventions for the selected mechanism, where the
 270       tokens of the selected mechanism are encapsulated until the
 271       GSS_S_COMPLETE is returned for both the initiator and the target.
 272       When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
 273       parameter is not yet valid.
 274
 275       When GSS_S_COMPLETE is returned, the mech_type output parameter
 276       indicates the selected mechanism. When the final negotiation token
 277       does not contain a MIC, the initiator GSS-API implementation must
 278       check the returned/selected mechanism is on the originally
 279
 280
 281
 282 Baize & Pinkas              Standards Track                     [Page 5]
 283 \f
 284 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 285
 286
 287       submitted list of mechanisms and also verify that the selected
 288       mechanism is not able to support a MIC. When the final negotiation
 289       token contains a MIC over the initial mechanisms list sent by the
 290       initiator, the MIC must be verified.
 291
 292    Note that the *_req_flag input parameters for context establishment
 293    are relative to the selected mechanism, as are the *_state output
 294    parameters. i.e., these parameters are not applicable to the
 295    negotiation process per se.
 296
 297    The initiator GSS-API calling application may need to know when the
 298    negotiation exchanges were protected or not. For this, when
 299    GSS_S_COMPLETE is returned, it can simply test the integ_avail flag.
 300    When this flag is set it indicates that the negotiation was
 301    protected.
 302
 303    On receipt of a negotiation token on the target side, a GSS-API
 304    implementation that does not support negotiation would indicate the
 305    GSS_S_BAD_MECH status as if a particular basic security mechanism had
 306    been requested but was not supported.
 307
 308    When GSS_Acquire_cred is invoked with the negotiation mechanism as
 309    desired_mechs, an implementation-specific default credential is used
 310    to carry on the negotiation. A set of mechanisms as specified locally
 311    by the system administrator is then available for negotiation. If
 312    there is a desire for the caller to make its own choice, then an
 313    additional API has to be used (see Appendix A).
 314
 315 3.  DATA ELEMENTS
 316
 317 3.1.  Mechanism Type
 318
 319    MechType::= OBJECT IDENTIFIER
 320
 321    mechType
 322         Each security mechanism is as defined in [1].
 323
 324 3.2.  Negotiation Tokens
 325
 326    The syntax of the negotiation tokens follows the InitialContextToken
 327    syntax defined in [1]. The security mechanism of the initial
 328    negotiation token is identified by the Object Identifier
 329    iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
 330
 331
 332
 333
 334
 335
 336
 337
 338 Baize & Pinkas              Standards Track                     [Page 6]
 339 \f
 340 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 341
 342
 343 3.2.1. Syntax
 344
 345    This section specifies the syntax of the corresponding
 346    "innerContextToken" field for the first token and subsequent
 347    negotiation tokens. During the mechanism negociation, the
 348    "innerContextToken" field contains the ASN.1 structure
 349    "NegociationToken" given below, encoded using the DER encoding
 350    conventions.
 351
 352 NegotiationToken ::= CHOICE {
 353                               negTokenInit  [0]  NegTokenInit,
 354                               negTokenTarg  [1]  NegTokenTarg }
 355
 356 MechTypeList ::= SEQUENCE OF MechType
 357
 358 NegTokenInit ::= SEQUENCE {
 359                             mechTypes       [0] MechTypeList  OPTIONAL,
 360                             reqFlags        [1] ContextFlags  OPTIONAL,
 361                             mechToken       [2] OCTET STRING  OPTIONAL,
 362                             mechListMIC     [3] OCTET STRING  OPTIONAL
 363                          }
 364
 365 ContextFlags ::= BIT STRING {
 366         delegFlag       (0),
 367         mutualFlag      (1),
 368         replayFlag      (2),
 369         sequenceFlag    (3),
 370         anonFlag        (4),
 371         confFlag        (5),
 372         integFlag       (6)
 373 }
 374
 375 negTokenInit
 376      Negotiation token sent by the initiator to the target, which
 377      contains, for the first token sent, one or more security mechanisms
 378      supported by the initiator (as indicated in the field mechTypes)
 379      and the service options (reqFlags) that are requested to establish
 380      the context. The context flags should be filled in from the
 381      req_flags parameter of init_sec_context().
 382
 383      The mechToken field is optional for the first token sent that all
 384      target implementations would not have to support. However for those
 385      targets that do support piggybacking the initial mechToken, an
 386      optimistic negotiation response is possible. Otherwise the
 387      mechToken is used to carry the tokens specific to the mechanism
 388      selected.
 389
 390
 391
 392
 393
 394 Baize & Pinkas              Standards Track                     [Page 7]
 395 \f
 396 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 397
 398
 399      The mechListMIC is an optional field. In the case that the chosen
 400      mechanism supports integrity, the initiator may optionally include
 401      a mechListMIC which is the result of a GetMIC of the MechTypes in
 402      the initial NegTokenInit and return GSS_S_COMPLETE.
 403
 404      When the chosen mechanism uses an odd number of messages, the final
 405      mechanism token will be sent from the initiator to the acceptor. In
 406      this case, there is a tradeoff between using the optimal number of
 407      messages, or using an additional message from the acceptor to the
 408      initiator in order to give the initiator assurance that no
 409      modification of the initiator's mechanism list occurred. The
 410      implementation can choose which tradeoff to make (see section 4.2.2
 411      for further details for the processing of that field).
 412
 413 NegTokenTarg ::= SEQUENCE {
 414     negResult      [0] ENUMERATED {
 415                             accept_completed    (0),
 416                             accept_incomplete   (1),
 417                             reject              (2) }          OPTIONAL,
 418     supportedMech  [1] MechType                                OPTIONAL,
 419     responseToken  [2] OCTET STRING                            OPTIONAL,
 420     mechListMIC    [3] OCTET STRING                            OPTIONAL
 421 }
 422
 423 negTokenTarg
 424      Negotiation token returned by the target to the initiator which
 425      contains, for the first token returned, a global negotiation result
 426      and the security mechanism selected (if any).
 427
 428 negResult
 429      The result accept_completed indicates that a context has been
 430      successfully established, while the result accept_incomplete
 431      indicates that additional token exchanges are needed.
 432
 433           Note: For the case where (a) a single-token context setup is
 434           used and (b) the preferred mechanism does not support the
 435           integrity facility which would cause a mechListMIC to be
 436           generated and enclosed, this feature allows to make a
 437           difference between a mechToken sent by the initiator but not
 438           processed by the target (accept_incomplete) and a mechToken
 439           sent by the initiator and processed by the target
 440           (accept_completed).
 441
 442      For those targets that support piggybacking the initial mechToken,
 443      an optimistic negotiation response is possible and includes in that
 444      case a responseToken which may continue the authentication exchange
 445      (e.g. when mutual authentication has been requested or when
 446      unilateral authentication requires several round trips). Otherwise
 447
 448
 449
 450 Baize & Pinkas              Standards Track                     [Page 8]
 451 \f
 452 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 453
 454
 455      the responseToken is used to carry the tokens specific to the
 456      mechanism selected. For subsequent tokens (if any) returned by the
 457      target, negResult, and supportedMech are not present.
 458
 459      For the last token returned by the target, the mechListMIC, when
 460      present, is a MIC computed over the MechTypes using the selected
 461      mechanism.
 462
 463 negResult
 464      Result of the negotiation exchange, specified by the target.
 465
 466      This can be either :
 467
 468           accept_completed
 469                The target accepts the preferred security mechanism,
 470                 and the context is established for the target or,
 471
 472           accept_incomplete
 473                The target accepts one of the proposed security
 474                mechanisms and further exchanges are necessary, or,
 475
 476           reject
 477                The target rejects all the proposed security
 478                mechanisms.
 479
 480 supportedMech
 481      This field has to be present when negResult is "accept_completed"
 482      or "accept_incomplete". It is a choice from the mechanisms offered
 483      by the initiator.
 484
 485 responseToken
 486      This field may be used either to transmit the response to the
 487      mechToken when sent by the initiator and when the first mechanism
 488      from the list has been selected by the target or to carry the
 489      tokens specific to the selected security mechanism.
 490
 491 mechListMIC
 492      If the selected mechanism is capable of integrity protection, this
 493      field must be present in the last message of the negotiation,
 494      (i.e., when the underlying mechanism returns a non-empty token and
 495      a major status of GSS_S_COMPLETE); it contains the result of a
 496      GetMIC of the MechTypes field in the initial NegTokenInit.  It
 497      allows to verify that the list initially sent by the initiator has
 498      been received unmodified by the target.
 499
 500
 501
 502
 503
 504
 505
 506 Baize & Pinkas              Standards Track                     [Page 9]
 507 \f
 508 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 509
 510
 511 3.2.2. Processing of mechListMIC.
 512
 513    If the mechanism selected by the negotiation does not support
 514    integrity, then no mechListMIC is included, otherwise a mechListMIC
 515    must be used and validated as indicated below.
 516
 517    If the mechanism supports integrity and uses an even number of
 518    messages, then the target must compute a MIC as described above, and
 519    send this in the final NegTokenTarg along with the final mechToken.
 520    The initiator when receiving the last token must require that the
 521    mechListMIC field be present and valid. In the absence of a valid
 522    mechListMIC, the negotiation must fail as if the last context
 523    establishment token was invalid.
 524
 525    In the case that the chosen mechanism supports integrity and uses an
 526    odd number of messages, the final mechanism token will be sent from
 527    the initiator to the target. In this case, there is a tradeoff
 528    between using the optimal number of messages, or using an additional
 529    message from the target to the initiator in order to give the
 530    initiator assurance that no modification of the initiator's mechanism
 531    list occurred. The implementation can choose which tradeoff to make.
 532
 533    When generating the final NegTokenInit message, the NegTokenInit may
 534    optionally include a mechListMIC which is the result of a GetMIC of
 535    the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE.
 536    The target must check the presence of the MIC computed over the
 537    mechList sent in the initial NegTokenInit. Three cases may then be
 538    considered:
 539
 540       1) If the mechListMIC is present and correct, then
 541          GSS_S_COMPLETE is returned to the target with no token; the
 542          context is established by the target.
 543
 544       2) If the mechListMIC is present but invalid, then the context
 545          establishment must fail.  An error major status code is
 546          returned to the target.
 547
 548       3) If the mechListMIC is not included in the final NegTokenInit,
 549          then GSS_S_COMPLETE must be returned to the target with a
 550          token. This token must be a NegTokenTarg, with a MIC included
 551          as described above, and no responseToken.  The application will
 552          then send this token back to the initiator, which must verify
 553          that the mechListMIC field is present and valid.
 554
 555
 556
 557
 558
 559
 560
 561
 562 Baize & Pinkas              Standards Track                    [Page 10]
 563 \f
 564 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 565
 566
 567          Note: If the MIC was originally sent by the initiator, but
 568                 thenafter deleted by an attacker, the target will send
 569                 back a token according to the description above, but the
 570                 initiator will be unable to process that returned token
 571                 and the context establishment must then fail.
 572
 573 4.  EXAMPLES : SECURITY MECHANISM NEGOTIATION
 574
 575    Here are some examples of security mechanism negotiation between an
 576    initiator (I) and a target (T).
 577
 578 4.1.  Initial steps
 579
 580    (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
 581
 582    (I) invokes GSS_Init_sec_context() with :
 583
 584    Input
 585      mech_type = OID for negotiation mechanism or NULL, if the
 586      negotiation mechanism is the default mechanism.
 587
 588    Output
 589      major_status = GSS_S_CONTINUE_NEEDED
 590      output_token = negTokenInit
 591
 592    The negotiation token (negTokenInit) contains two security mechanisms
 593    with :
 594      mechType = GSS-MECH1 or
 595      mechType = GSS-MECH2
 596
 597    (I) sends to (T) the negotiation token.
 598
 599 4.2  Successful negotiation steps
 600
 601    (T) supports GSS-MECH2
 602    (T) receives the negotiation token (negTokenInit) from (I)
 603    (T) invokes GSS_Accept_sec_context() with :
 604
 605    Input
 606         input_token = negTokenInit
 607
 608    Output
 609         major_status = GSS_S_CONTINUE_NEEDED
 610         output_token = negTokenTarg
 611
 612    The negotiation token (negTokenTarg) contains :
 613         negResult = accept (the negotiation result)
 614         supportedMech : mechType = GSS-MECH2
 615
 616
 617
 618 Baize & Pinkas              Standards Track                    [Page 11]
 619 \f
 620 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 621
 622
 623    (T) returns the negotiation token (negTokenTarg) to (I)
 624    (I) invokes GSS_Init_sec_context() with :
 625
 626    Input
 627         input_token = negTokenTarg
 628
 629    Output
 630         major_status = GSS_S_COMPLETE
 631         output_token = initialContextToken (initial context token
 632                                             for GSS-MECH2)
 633         mech_type = GSS-MECH2
 634
 635    The subsequent steps are security mechanism specific, and work as
 636    specified in [1].  The output tokens from the security mechanism are
 637    encapsulated in a NegTokenTarg message (with the supportedMech field
 638    omitted, and the mechListMIC included with the last token).
 639
 640 4.3.  Failed negotiation steps
 641
 642    (T) supports GSS-MECH3.
 643    (T) receives the negotiation token (negTokenInit) from (I)
 644    (T) invokes GSS_Accept_sec_context() with :
 645
 646    Input
 647         input_token = negTokenInit
 648
 649    Output
 650         major_status = GSS_S_BAD_MECH
 651         output_token = negTokenTarg
 652
 653    The negotiation token (negTokenTarg) contains :
 654
 655         negResult = reject (the negotiation result)
 656
 657    (T) returns the negotiation token (negTokenTarg) to (I)
 658    (I) invokes GSS_Init_sec_context() with :
 659
 660    Input
 661         input_token = negTokenTarg
 662
 663    Output
 664         major_status = GSS_S_BAD_MECH
 665
 666    The security context establishment has failed.
 667
 668
 669
 670
 671
 672
 673
 674 Baize & Pinkas              Standards Track                    [Page 12]
 675 \f
 676 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 677
 678
 679 4.4 Successful Negotiation with preferred mechanism info
 680
 681    (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
 682
 683    (I) invokes GSS_Init_sec_context() with :
 684
 685    Input
 686         mech_type = OID for negotiation mechanism or NULL, if the
 687         negotiation mechanism is the default mechanism.
 688
 689    Output
 690         major_status = GSS_S_CONTINUE_NEEDED
 691         output_token = negTokenInit
 692
 693    The negotiation token (negTokenInit) contains two security mechanisms
 694    with :
 695         mechType = GSS-MECH1 or
 696         mechType = GSS-MECH2
 697
 698         mechToken = output_token from GSS_Init_sec_context
 699        ( first mechType) as described in [1]
 700
 701    (I) sends to (T) the negotiation token.
 702
 703    (T) supports GSS-MECH1.
 704    (T) receives the negotiation token (negTokenInit) from (I)
 705    (T) invokes GSS_Accept_sec_context() with :
 706
 707    Input
 708         input_token = negTokenInit
 709
 710    Output
 711         major_status = GSS_S_CONTINUE_NEEDED
 712         output_token = negTokenTarg
 713
 714    The negotiation token (negTokenTarg) contains :
 715         negResult = accept (the negotiation result)
 716         supportedMech : mechType = GSS-MECH1
 717
 718         mechToken = output_token from
 719                          GSS_Accept_sec_context(mechToken )
 720
 721    (T) returns the negotiation token (negTokenTarg) to (I)
 722    (I) invokes GSS_Init_sec_context() with :
 723
 724    Input
 725         input_token = negTokenTarg
 726
 727
 728
 729
 730 Baize & Pinkas              Standards Track                    [Page 13]
 731 \f
 732 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 733
 734
 735    Output
 736         major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed
 737         output_token = ContextToken (initial or subsequent context token
 738                        for GSS-MECH1)
 739         mech_type = GSS-MECH1
 740
 741    Specific implementations of the protocol can support the optimistic
 742    negotiation by completing the security context establishment using the
 743    agreed upon mechanism as described in [1].  As described above in
 744    section 5.2, the output tokens from the security mechanisms are
 745    encapsulated in a NegTokenTarg message (with the negResult and
 746    supportedMech fields omitted, and the mechListMIC included with the
 747    last token).
 748
 749 5.  SECURITY CONSIDERATIONS
 750
 751    When the mechanism selected by the target from the list supplied by
 752    the initiator supports integrity protection, then the negotiation is
 753    protected.
 754
 755    When one of the mechanisms proposed by the initiator does not support
 756    integrity protection, then the negotiation is exposed to all threats
 757    a non secured service is exposed. In particular, an active attacker
 758    can force to use a security mechanism which is not the common
 759    preferred one (when multiple security mechanisms are shared between
 760    peers) but which is acceptable anyway to the target.
 761
 762    In any case, the communicating peers may be exposed to the denial of
 763    service threat.
 764
 765 6.  ACKNOWLEDGMENTS
 766
 767    Acknowledgments are due to Stephen Farrell of SSE, Marc Horowitz of
 768    Stonecast, John Linn of RSA Laboratories, Piers McMahon of Platinum
 769    Technology, Tom Parker of ICL and Doug Rosenthal of EINet, for
 770    reviewing earlier versions of this document and for providing useful
 771    inputs. Acknowledgments are also due to Peter Brundrett of Microsoft
 772    for his proposal for an optimistic negotiation, and for Bill
 773    Sommerfeld of Epilogue Technology for his proposal for protecting the
 774    negotiation.
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Baize & Pinkas              Standards Track                    [Page 14]
 787 \f
 788 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 789
 790
 791 APPENDIX A
 792
 793
 794    GSS-API NEGOTIATION SUPPORT API
 795
 796    In order to provide to a GSS-API caller (either the initiator or the
 797    target or both) the ability to choose among the set of supported
 798    mechanisms a reduced set of mechanisms for negotiation, two
 799    additional APIs are defined:
 800
 801    GSS_Get_neg_mechs() indicates the set of security mechanisms
 802    available on the local system to the caller for negotiation.
 803
 804    GSS_Set_neg_mechs() specifies the set of security mechanisms to be
 805    used on the local system by the caller for negotiation.
 806
 807 A.1.  GSS_Set_neg_mechs call
 808
 809    Input:
 810         cred_handle          CREDENTIAL HANDLE
 811                              - NULL specifies default credentials
 812         mech_set             SET OF OBJECT IDENTIFIER
 813
 814    Outputs:
 815         major_status INTEGER,
 816         minor_status INTEGER,
 817
 818    Return major_status codes :
 819      GSS_S_COMPLETE indicates that the set of security mechanisms
 820      available for negotiation has been set to mech_set. GSS_S_FAILURE
 821      indicates that the requested operation could not be performed for
 822      reasons unspecified at the GSS-API level.
 823
 824    Allows callers to specify the set of security mechanisms that may be
 825    negotiated with the credential identified by cred_handle. This call
 826    is intended for support of specialised callers who need to restrict
 827    the set of negotiable security mechanisms from the set of all
 828    security mechanisms available to the caller (based on available
 829    credentials). Note that if more than one mechanism is specified in
 830    mech_set, the order in which those mechanisms are specified implies a
 831    relative mechanism preference for the target.
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Baize & Pinkas              Standards Track                    [Page 15]
 843 \f
 844 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 845
 846
 847 A.2.  GSS_Get_neg_mechs call
 848
 849    Input:
 850         cred_handle    CREDENTIAL HANDLE
 851                        - NULL specifies default credentials
 852
 853    Outputs:
 854         major_status INTEGER,
 855         minor_status INTEGER,
 856         mech_set     SET OF OBJECT IDENTIFIER
 857
 858    Return major_status codes :
 859         GSS_S_COMPLETE indicates that the set of security mechanisms
 860         available for negotiation has been returned in
 861         mech_option_set.
 862         GSS_S_FAILURE indicates that the requested operation could not
 863         be performed for reasons unspecified at the GSS-API level.
 864
 865    Allows callers to determine the set of security mechanisms available
 866    for negotiation with the credential identified by cred_handle. This
 867    call is intended for support of specialised callers who need to
 868    reduce the set of negotiable security mechanisms from the set of
 869    supported security mechanisms available to the caller (based on
 870    available credentials).
 871
 872    Note: The GSS_Indicate_mechs() function indicates the full set of
 873    mechanism types available on the local system. Since this call has no
 874    input parameter, the returned set is not necessarily available for
 875    all credentials.
 876
 877 REFERENCES
 878
 879    [1] Linn, J., "Generic Security Service Application Program
 880        Interface", RFC 2078, January 1997.
 881
 882    [2] Standard ECMA-206, "Association Context Management including
 883        Security Context Management", December 1993.  Available on
 884        http://www.ecma.ch
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898 Baize & Pinkas              Standards Track                    [Page 16]
 899 \f
 900 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 901
 902
 903 AUTHORS' ADDRESSES
 904
 905    Eric Baize
 906    Bull - 300 Concord Road
 907    Billerica, MA 01821 - USA
 908
 909    Phone: +1 978 294 61 37
 910    Fax: +1 978 294 61 09
 911    EMail: Eric.Baize@bull.com
 912
 913
 914    Denis Pinkas
 915    Bull
 916    Rue Jean-Jaures
 917    BP 68
 918    78340 Les Clayes-sous-Bois - FRANCE
 919
 920    Phone: +33 1 30 80 34 87
 921    Fax: +33 1 30 80 33 21
 922    EMail: Denis.Pinkas@bull.net
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954 Baize & Pinkas              Standards Track                    [Page 17]
 955 \f
 956 RFC 2478             GSS-API Negotiation Mechanism         December 1998
 957
 958
 959 Full Copyright Statement
 960
 961    Copyright (C) The Internet Society (1998).  All Rights Reserved.
 962
 963    This document and translations of it may be copied and furnished to
 964    others, and derivative works that comment on or otherwise explain it
 965    or assist in its implementation may be prepared, copied, published
 966    and distributed, in whole or in part, without restriction of any
 967    kind, provided that the above copyright notice and this paragraph are
 968    included on all such copies and derivative works.  However, this
 969    document itself may not be modified in any way, such as by removing
 970    the copyright notice or references to the Internet Society or other
 971    Internet organizations, except as needed for the purpose of
 972    developing Internet standards in which case the procedures for
 973    copyrights defined in the Internet Standards process must be
 974    followed, or as required to translate it into languages other than
 975    English.
 976
 977    The limited permissions granted above are perpetual and will not be
 978    revoked by the Internet Society or its successors or assigns.
 979
 980    This document and the information contained herein is provided on an
 981    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 982    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 983    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 984    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 985    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010 Baize & Pinkas              Standards Track                    [Page 18]
1011 \f