third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-05.txt

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                                  P. Leach
   5 Obsoletes: 2478 (if approved)                              K. Jaganathan
   6 Expires: July 27, 2005                             Microsoft Corporation
   7                                                             W. Ingersoll
   8                                                         Sun Microsystems
   9                                                         January 23, 2005
  10
  11
  12          The Simple and Protected GSS-API Negotiation Mechanism
  13                       draft-ietf-kitten-2478bis-05
  14
  15 Status of this Memo
  16
  17    This document is an Internet-Draft and is subject to all provisions
  18    of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
  19    author represents that any applicable patent or other IPR claims of
  20    which he or she is aware have been or will be disclosed, and any of
  21    which he or she become aware will be disclosed, in accordance with
  22    RFC 3668.
  23
  24    Internet-Drafts are working documents of the Internet Engineering
  25    Task Force (IETF), its areas, and its working groups.  Note that
  26    other groups may also distribute working documents as
  27    Internet-Drafts.
  28
  29    Internet-Drafts are draft documents valid for a maximum of six months
  30    and may be updated, replaced, or obsoleted by other documents at any
  31    time.  It is inappropriate to use Internet-Drafts as reference
  32    material or to cite them other than as "work in progress."
  33
  34    The list of current Internet-Drafts can be accessed at
  35    http://www.ietf.org/ietf/1id-abstracts.txt.
  36
  37    The list of Internet-Draft Shadow Directories can be accessed at
  38    http://www.ietf.org/shadow.html.
  39
  40    This Internet-Draft will expire on July 27, 2005.
  41
  42 Copyright Notice
  43
  44    Copyright (C) The Internet Society (2005).
  45
  46 Abstract
  47
  48    This document specifies a negotiation mechanism for the Generic
  49    Security Service Application Program Interface (GSS-API) which is
  50    described in RFC 2743.
  51
  52
  53
  54 Zhu, et al.               Expires July 27, 2005                 [Page 1]
  55 \f
  56 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
  57
  58
  59    GSS-API peers can use this negotiation mechanism to choose from a
  60    common set of security mechanisms.
  61
  62    If per-message integrity services are available on the established
  63    mechanism context, then the negotiation is protected against an
  64    attacker forcing the selection of a mechanism not desired by the
  65    peers.
  66
  67    This mechanism replaces RFC 2478 in order to fix defects in that
  68    specification and to describe how to inter-operate with
  69    implementations of that specification commonly deployed on the
  70    Internet.
  71
  72 Table of Contents
  73
  74    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  75    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
  76    3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
  77      3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
  78      3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
  79    4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . . 10
  80      4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . . 10
  81      4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
  82        4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
  83        4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
  84    5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 14
  85    6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 17
  86    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
  87    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
  88    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
  89    10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 21
  90      10.1  Normative References . . . . . . . . . . . . . . . . . . . 21
  91      10.2  Informative References . . . . . . . . . . . . . . . . . . 21
  92        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
  93    A.  SPNEGO ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 23
  94    B.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 25
  95      B.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 25
  96      B.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 25
  97    C.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 27
  98    D.  mechListMIC Computation Example  . . . . . . . . . . . . . . . 29
  99        Intellectual Property and Copyright Statements . . . . . . . . 30
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110 Zhu, et al.               Expires July 27, 2005                 [Page 2]
 111 \f
 112 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 113
 114
 115 1.  Introduction
 116
 117    The GSS-API [RFC2743] provides a generic interface which can be
 118    layered atop different security mechanisms such that if communicating
 119    peers acquire GSS-API credentials for the same security mechanism,
 120    then a security context may be established between them (subject to
 121    policy).  However, GSS-API does not prescribe the method by which
 122    GSS-API peers can establish whether they have a common security
 123    mechanism.
 124
 125    The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
 126    defined here is a pseudo security mechanism, which enables GSS-API
 127    peers to determine in-band whether their credentials support a common
 128    set of one or more GSS-API security mechanisms, and if so, to invoke
 129    the normal security context establishment for a selected common
 130    security mechanism.  This is most useful for applications which
 131    depend on GSS-API implementations and share multiple mechanisms
 132    between the peers.
 133
 134    The SPNEGO mechanism negotiation is based on the following model: the
 135    initiator proposes a list of security mechanism(s), in decreasing
 136    preference order (favorite choice first), the acceptor (also known as
 137    the target) either accepts the initiator's preferred security
 138    mechanism (the first in the list), or chooses one that is available
 139    from the offered list, or rejects the proposed value(s).  The target
 140    then informs the initiator of its choice.
 141
 142    Once a common security mechanism is chosen, mechanism-specific
 143    options MAY be negotiated as part of the selected mechanism's context
 144    establishment.  These negotiations (if any) are internal to the
 145    mechanism and opaque to the SPNEGO protocol.  As such they are
 146    outside the scope of this document.
 147
 148    If per-message integrity services are available on the established
 149    mechanism security context, then the negotiation is protected to
 150    ensure that the mechanism list has not been modified.  In cases where
 151    an attacker could have materially influenced the negotiation, peers
 152    exchange message integrity code (MIC) tokens to confirm the mechanism
 153    list has not been modified.  If no action of an attacker could have
 154    materially modified the outcome of the negotiation, the exchange of
 155    MIC tokens is optional (see Section 5).  Allowing MIC tokens to be
 156    optional in this case provides interoperability with existing
 157    implementations while still protecting the negotiation.  This
 158    interoperability comes at the cost of increased complexity.
 159
 160    SPNEGO relies on the concepts developed in the GSS-API specification
 161    [RFC2743].  The negotiation data is encapsulated in context-level
 162    tokens.  Therefore, callers of the GSS-API do not need to be aware of
 163
 164
 165
 166 Zhu, et al.               Expires July 27, 2005                 [Page 3]
 167 \f
 168 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 169
 170
 171    the existence of the negotiation tokens but only of the new
 172    pseudo-security mechanism.  A failure in the negotiation phase causes
 173    a major status code to be returned: GSS_S_BAD_MECH.
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222 Zhu, et al.               Expires July 27, 2005                 [Page 4]
 223 \f
 224 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 225
 226
 227 2.  Conventions Used in This Document
 228
 229    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 230    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 231    document are to be interpreted as described in [RFC2119].
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278 Zhu, et al.               Expires July 27, 2005                 [Page 5]
 279 \f
 280 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 281
 282
 283 3.  Negotiation Protocol
 284
 285    When the established mechanism context provides integrity protection,
 286    the mechanism negotiation can be protected.  When acquiring
 287    negotiated security mechanism tokens, per-message integrity services
 288    are always requested by the SPNEGO mechanism.
 289
 290    When the established mechanism context supports per-message integrity
 291    services, SPNEGO guarantees that the selected mechanism is mutually
 292    preferred.
 293
 294    This section describes the negotiation process of this protocol.
 295
 296 3.1  Negotiation Description
 297
 298    The first negotiation token sent by the initiator contains an ordered
 299    list of mechanisms in decreasing preference order (favorite mechanism
 300    first), and optionally the initial mechanism token for the preferred
 301    mechanism of the initiator (i.e., the first in the list).  (Note that
 302    the list MUST NOT contain either this SPNEGO mechanism itself or any
 303    mechanism for which the client does not have appropriate
 304    credentials.)
 305
 306    The target then processes the token from the initiator.  This will
 307    result in one of four possible states (as defined in Section 4.2.2)
 308    being returned in the reply message: accept-completed,
 309    accept-incomplete, reject, or request-mic.  A reject state will
 310    terminate the negotiation;  an accept-completed state indicates that
 311    not only was the initiator-selected mechanism acceptable to the
 312    target, but also that the security mechanism token embedded in the
 313    first negotiation message was sufficient to complete the
 314    authentication;  an accept-incomplete state indicates that further
 315    message exchange is needed but the MIC token exchange as described in
 316    Section 5 is OPTIONAL;  a request-mic state (this state can only be
 317    present in the first reply message from the target) indicates the MIC
 318    token exchange is REQUIRED if per-message integrity services are
 319    available.
 320
 321    Unless the preference order is specified by the application, the
 322    policy by which the target chooses a mechanism is an
 323    implementation-specific local matter.  In the absence of an
 324    application specified preference order or other policy, the target
 325    SHALL choose the first mechanism in the initiator proposed list for
 326    which it has valid credentials.
 327
 328    In case of a successful negotiation, the security mechanism in the
 329    first reply message represents the value suitable for the target,
 330    chosen from the list offered by the initiator.
 331
 332
 333
 334 Zhu, et al.               Expires July 27, 2005                 [Page 6]
 335 \f
 336 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 337
 338
 339    In case of an unsuccessful negotiation, the reject state is returned
 340    and generating a context level negotiation token is OPTIONAL.
 341
 342    Once a mechanism has been selected, context establishment tokens
 343    specific to the selected mechanism are carried within the negotiation
 344    tokens.
 345
 346    Lastly, MIC tokens may be exchanged to ensure the authenticity of the
 347    mechanism list received by the target.
 348
 349    To avoid conflicts with the use of MIC tokens by SPNEGO,
 350    partially-established contexts MUST NOT be used for per-message
 351    calls.  To guarantee this, the prot_ready_state [RFC2743] MUST be set
 352    to false on return from GSS_Init_sec_context() and
 353    GSS_Accept_sec_context() even if the underlying mechanism returned
 354    true.
 355
 356    Note that in order to avoid an extra round trip, the first context
 357    establishment token of the initiator's preferred mechanism SHOULD be
 358    embedded in the initial negotiation message (as defined in
 359    Section 4.2).  (This mechanism token is referred to as the optimistic
 360    mechanism token in this document.) In addition, using the optimistic
 361    mechanism token allows the initiator to recover from non-fatal errors
 362    encountered trying to produce the first mechanism token before a
 363    mechanism can be selected.  Implementations MAY omit the optimistic
 364    mechanism token in cases where the likelihood of the initiator's
 365    preferred mechanism not being selected by the acceptor is significant
 366    given the cost of generating it.
 367
 368 3.2  Negotiation Procedure
 369
 370    The basic form of the procedure assumes that per-message integrity
 371    services are available on the established mechanism context, and it
 372    is summarized as follows:
 373
 374    (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
 375       but requests that SPNEGO be used.  SPNEGO can either be explicitly
 376       requested or accepted as the default mechanism.
 377
 378    (b) The initiator GSS-API implementation generates a negotiation
 379       token containing a list of one or more security mechanisms that
 380       are available based on the credentials used for this context
 381       establishment, and optionally the initial mechanism token for the
 382       first mechanism in the list.
 383
 384
 385
 386
 387
 388
 389
 390 Zhu, et al.               Expires July 27, 2005                 [Page 7]
 391 \f
 392 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 393
 394
 395    (c) The GSS-API initiator application sends the token to the target
 396       application.  The GSS-API target application passes the token by
 397       invoking GSS_Accept_sec_context().  The acceptor will do one of
 398       the following:
 399
 400
 401          (I) If none of the proposed mechanisms are acceptable, the
 402             negotiation SHALL be terminated.  GSS_Accept_sec_context
 403             indicates GSS_S_BAD_MECH.  The acceptor MAY output a
 404             negotiation token containing a reject state.
 405
 406          (II) If either the initiator's preferred mechanism is not
 407             accepted by the target or this mechanism is accepted but it
 408             is not the acceptor's most preferred mechanism (i.e., the
 409             MIC token exchange as described in Section 5 is required),
 410             GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
 411             The acceptor MUST output a negotiation token containing a
 412             request-mic state.
 413
 414          (III) Otherwise if at least one additional negotiation token
 415             from the initiator is needed to establish this context,
 416             GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
 417             outputs a negotiation token containing an accept-incomplete
 418             state.
 419
 420          (IV) Otherwise no additional negotiation token from the
 421             initiator is needed to establish this context,
 422             GSS_Accept_sec_context() indicates GSS_S_COMPLETE and
 423             outputs a negotiation token containing an accept_complete
 424             state.
 425
 426       If the initiator's preferred mechanism is accepted, and an
 427       optimistic mechanism token was included, this mechanism token MUST
 428       be passed to the selected mechanism by invoking
 429       GSS_Accept_sec_context() and if a response mechanism token is
 430       returned, it MUST be included in the response negotiation token.
 431       Otherwise, the target will not generate a response mechanism token
 432       in the first reply.
 433
 434    (d) The GSS-API target application returns the negotiation token to
 435       the initiator application.  The GSS-API initiator application
 436       passes the token by invoking GSS_Init_sec_context().  The security
 437       context initialization is then continued according to the standard
 438       GSS-API conventions for the selected mechanism, where the tokens
 439       of the selected mechanism are encapsulated in negotiation messages
 440       (see Section 4) until GSS_S_COMPLETE is returned for both the
 441       initiator and the target by the selected security mechanism.
 442
 443
 444
 445
 446 Zhu, et al.               Expires July 27, 2005                 [Page 8]
 447 \f
 448 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 449
 450
 451    (e) MIC tokens are then either skipped or exchanged according to
 452       Section 5.
 453
 454    Note that the *_req_flag input parameters for context establishment
 455    are relative to the selected mechanism, as are the *_state output
 456    parameters.  i.e., these parameters are not applicable to the
 457    negotiation process per se.
 458
 459    On receipt of a negotiation token on the target side, a GSS-API
 460    implementation that does not support negotiation would indicate the
 461    GSS_S_BAD_MECH status as if a particular basic security mechanism had
 462    been requested and was not supported.
 463
 464    When a GSS-API credential is acquired for the SPNEGO mechanism the
 465    implementation SHOULD produce a credential element for the SPNEGO
 466    mechanism which internally contains GSS-API credential elements for
 467    all mechanisms for which the principal has credentials available,
 468    except for any mechanisms which are not to be negotiated, either as
 469    per implementation-, site- or application-specific policy.  See
 470    Appendix B for interfaces for expressing application policy.
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502 Zhu, et al.               Expires July 27, 2005                 [Page 9]
 503 \f
 504 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 505
 506
 507 4.  Token Definitions
 508
 509    The type definitions in this section assume an ASN.1 module
 510    definition of the following form:
 511
 512
 513        SPNEGOASNOneSpec {
 514           iso(1) identified-organization(3) dod(6) internet(1)
 515           security(5) mechanism(5) snego (2) modules(4) spec2(2)
 516        } DEFINITIONS EXPLICIT TAGS ::= BEGIN
 517
 518        -- rest of definitions here
 519
 520        END
 521
 522
 523    This specifies that the tagging context for the module will be
 524    explicit and non-automatic.
 525
 526    The encoding of SPNEGO protocol messages shall obey the Distinguished
 527    Encoding Rules (DER) of ASN.1 as described in [X690].
 528
 529 4.1  Mechanism Types
 530
 531    In this negotiation model, each OID represents one GSS-API mechanism
 532    or one variant (see Section 6) of it according to [RFC2743].
 533
 534
 535        MechType ::= OBJECT IDENTIFIER
 536            -- OID represents each security mechanism as suggested by
 537            -- [RFC2743]
 538
 539        MechTypeList ::= SEQUENCE OF MechType
 540
 541
 542 4.2  Negotiation Tokens
 543
 544    The syntax of the initial negotiation tokens follows the
 545    initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
 546    SPNEGO pseudo mechanism is identified by the Object Identifier
 547    iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
 548    Subsequent tokens MUST NOT be encapsulated in this GSS-API generic
 549    token framing.
 550
 551    This section specifies the syntax of the inner token for the initial
 552    message and the syntax of subsequent context establishment tokens.
 553
 554
 555
 556
 557
 558 Zhu, et al.               Expires July 27, 2005                [Page 10]
 559 \f
 560 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 561
 562
 563        NegotiationToken ::= CHOICE {
 564            negTokenInit    [0] NegTokenInit,
 565            negTokenResp    [1] NegTokenResp
 566        }
 567
 568
 569
 570 4.2.1  negTokenInit
 571
 572        NegTokenInit ::= SEQUENCE {
 573            mechTypes       [0] MechTypeList,
 574            reqFlags        [1] ContextFlags  OPTIONAL,
 575              -- inherited from RFC 2478 for backward compatibility,
 576              -- RECOMMENDED to be left out
 577            mechToken       [2] OCTET STRING  OPTIONAL,
 578            mechListMIC     [3] OCTET STRING  OPTIONAL,
 579            ...
 580        }
 581        ContextFlags ::= BIT STRING {
 582            delegFlag       (0),
 583            mutualFlag      (1),
 584            replayFlag      (2),
 585            sequenceFlag    (3),
 586            anonFlag        (4),
 587            confFlag        (5),
 588            integFlag       (6)
 589        } (SIZE (32))
 590
 591    This is the syntax for the inner token of the initial negotiation
 592    message.
 593
 594    mechTypes
 595
 596          This field contains one or more security mechanisms available
 597          for the initiator in decreasing preference order (favorite
 598          choice first).
 599
 600    reqFlags
 601
 602          This field, if present, contains the service options that are
 603          requested to establish the context (the req_flags parameter of
 604          GSS_Init_sec_context()).  This field is inherited from RFC 2478
 605          and it is not integrity protected.  For implementations of this
 606          specification the initiator SHOULD omit this reqFlags field,
 607          and the acceptor MUST ignore this reqFlags field.
 608
 609
 610
 611
 612
 613
 614 Zhu, et al.               Expires July 27, 2005                [Page 11]
 615 \f
 616 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 617
 618
 619    mechToken
 620
 621          This field, if present, contains the optimistic mechanism
 622          token.
 623
 624    mechlistMIC
 625
 626          This field, if present, contains a MIC token for the mechanism
 627          list in the initial negotiation message.  This MIC token is
 628          computed according to Section 5.
 629
 630
 631 4.2.2  negTokenResp
 632
 633        NegTokenResp ::= SEQUENCE {
 634            negState       [0] ENUMERATED {
 635                accept-completed    (0),
 636                accept-incomplete   (1),
 637                reject              (2),
 638                request-mic         (3)
 639            }                                 OPTIONAL,
 640              -- REQUIRED in the first reply from the target
 641            supportedMech   [1] MechType      OPTIONAL,
 642              -- present only in the first reply from the target
 643            responseToken   [2] OCTET STRING  OPTIONAL,
 644            mechListMIC     [3] OCTET STRING  OPTIONAL,
 645            ...
 646        }
 647
 648    This is the syntax for all subsequent negotiation messages.
 649
 650    negState
 651
 652          This field, if present, contains the state of the negotiation.
 653          This can be:
 654
 655          accept-completed
 656
 657             No further negotiation message from the peer is expected,
 658             and the security context is established for the sender.
 659
 660          accept-incomplete
 661
 662             At least one more negotiation message from the peer is
 663             needed to establish the security context.
 664
 665
 666
 667
 668
 669
 670 Zhu, et al.               Expires July 27, 2005                [Page 12]
 671 \f
 672 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 673
 674
 675          reject
 676
 677             The sender terminates the negotiation.
 678
 679          request-mic
 680
 681             The sender indicates that the exchange of MIC tokens, as
 682             described in Section 5, will be REQUIRED if per-message
 683             integrity services are available on the mechanism context to
 684             be established.  This value SHALL only be present in the
 685             first reply from the target.
 686
 687          This field is REQUIRED in the first reply from the target, and
 688          it is OPTIONAL thereafter.  When negState is absent the actual
 689          state should be inferred from the state of the negotiated
 690          mechanism context.
 691
 692    supportedMech
 693
 694          This field SHALL only be present in the first reply from the
 695          target.  It MUST be one of the mechanism(s) offered by the
 696          initiator.
 697
 698    ResponseToken
 699
 700          This field, if present, contains tokens specific to the
 701          mechanism selected.
 702
 703    mechlistMIC
 704
 705          This field, if present, contains a MIC token for the mechanism
 706          list in the initial negotiation message.  This MIC token is
 707          computed according to Section 5.
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726 Zhu, et al.               Expires July 27, 2005                [Page 13]
 727 \f
 728 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 729
 730
 731 5.  Processing of mechListMIC
 732
 733    If the mechanism selected by the negotiation does not support
 734    integrity protection, then no mechlistMIC token is used.
 735
 736    Otherwise, if the accepted mechanism is the most preferred mechanism
 737    of both the initiator and the acceptor, then the MIC token exchange,
 738    as described later in this section, is OPTIONAL.  A mechanism is the
 739    acceptor's most preferred mechanism if there is no other mechanism
 740    which, had it been present in the mechanism list, the acceptor would
 741    have preferred over the accepted mechanism.
 742
 743    In all other cases, MIC tokens MUST be exchanged after the mechanism
 744    context is fully established.
 745
 746    a) The mechlistMIC token (or simply the MIC token) is computed over
 747       the mechanism list in the initial negotiation message by invoking
 748       GSS_GetMIC() as follows: the input context_handle is the
 749       established mechanism context, the input qop_req is 0, and the
 750       input message is the DER encoding of the value of type
 751       MechTypeList which is contained in the "mechTypes" field of the
 752       NegTokenInit.  The input message is NOT the DER encoding of the
 753       type "[0] MechTypeList".
 754
 755    b) If the selected mechanism exchanges an even number of mechanism
 756       tokens (i.e., the acceptor sends the last mechanism token), the
 757       acceptor does the following when generating the negotiation
 758       message containing the last mechanism token: if the MIC token
 759       exchange is optional, GSS_Accept_sec_context() either indicates
 760       GSS_S_COMPLETE and does not include a mechlistMIC token, or
 761       indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
 762       and an accept-incomplete state; if the MIC token exchange is
 763       required, GSS_Accept_sec_context() indicates
 764       GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
 765       Acceptors that wish to be compatible with legacy Windows SPNEGO
 766       implementations as described in Appendix C should not generate a
 767       mechlistMIC token when the MIC token exchange is not required.
 768       The initiator then processes the last mechanism token, and does
 769       one of the following:
 770
 771       (I) If a mechlistMIC token was included, and is correctly
 772          verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
 773          output negotiation message contains a mechlistMIC token, and an
 774          accept_complete state.  The acceptor MUST then verify this
 775          mechlistMIC token.
 776
 777
 778
 779
 780
 781
 782 Zhu, et al.               Expires July 27, 2005                [Page 14]
 783 \f
 784 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 785
 786
 787       (II) If a mechlistMIC token was included but is incorrect, the
 788          negotiation SHALL be terminated.  GSS_Init_sec_context()
 789          indicates GSS_S_DEFECTIVE_TOKEN.
 790
 791       (III) If no mechlistMIC token was included, and the MIC token
 792          exchange is not required, GSS_Init_sec_context() indicates
 793          GSS_S_COMPLETE with no output token.
 794
 795       (IV) If no mechlistMIC token was included, but the MIC token
 796          exchange is required, the negotiation SHALL be terminated.
 797          GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
 798
 799    c) In the case that the chosen mechanism exchanges an odd number of
 800       mechanism tokens (i.e., the initiator sends the last mechanism
 801       token), the initiator does the following when generating the
 802       negotiation message containing the last mechanism token: if the
 803       negState was request-mic in the first reply from the target, a
 804       mechlistMIC token MUST be included, otherwise the mechlistMIC
 805       token is OPTIONAL.  (Note that the MIC token exchange is required
 806       if a mechanism other than the initiator's first choice is chosen.)
 807       In the case that the optimistic mechanism token is the only
 808       mechanism token for the initiator's preferred mechanism, the
 809       mechlistMIC token is OPTIONAL.  Whether or not the mechlistMIC
 810       token is included, GSS_Init_sec_context() indicates
 811       GSS_S_CONTINUE_NEEDED.  Initiators that wish to be compatible with
 812       legacy Windows SPNEGO implementations as described in Appendix C
 813       should not generate a mechlistMIC token when the MIC token
 814       exchange is not required.  The acceptor then processes the last
 815       mechanism token and does one of the following:
 816
 817       (I) If a mechlistMIC token was included and is correctly verified,
 818          GSS_Accept_sec_context() indicates GSS_S_COMPLETE.  The output
 819          negotiation message contains a mechlistMIC token and an
 820          accept_complete state.  The initiator MUST then verify this
 821          mechlistMIC token.
 822
 823       (II) If a mechlistMIC token was included but is incorrect, the
 824          negotiation SHALL be terminated.  GSS_Accept_sec_context()
 825          indicates GSS_S_DEFECTIVE_TOKEN.
 826
 827       (III) If no mechlistMIC token was included and the mechlistMIC
 828          token exchange is not required, GSS_Accept_sec_context()
 829          indicates GSS_S_COMPLETE.  The output negotiation message
 830          contains an accept_complete state.
 831
 832
 833
 834
 835
 836
 837
 838 Zhu, et al.               Expires July 27, 2005                [Page 15]
 839 \f
 840 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 841
 842
 843       (IV) In the case that the optimistic mechanism token is also the
 844          last mechanism token (when the initiator's preferred mechanism
 845          is accepted by the target) and the target sends a request-mic
 846          state but the initiator did not send a mechlistMIC token, the
 847          target then MUST include a mechlistMIC token in that first
 848          reply.  GSS_Accept_sec_context() indicates
 849          GSS_S_CONTINUE_NEEDED.  The initiator MUST verify the received
 850          mechlistMIC token and generate a mechlistMIC token to send back
 851          to the target.  The target SHALL in turn verify the returned
 852          mechlistMIC token and complete the negotiation.
 853
 854       (V) If no mechlistMIC token was included and the acceptor sent a
 855          request-mic state in the first reply message (the exchange of
 856          MIC tokens is required), the negotiation SHALL be terminated.
 857          GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894 Zhu, et al.               Expires July 27, 2005                [Page 16]
 895 \f
 896 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 897
 898
 899 6.  Extensibility
 900
 901    Two mechanisms are provided for extensibility.  First, the ASN.1
 902    structures in this specification MAY be expanded by IETF standards
 903    action.  Implementations receiving unknown fields MUST ignore these
 904    fields.
 905
 906    Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
 907    mechanism variants) may be included in the set of preferred
 908    mechanisms by an initiator.  The acceptor can choose to honor this
 909    request by preferring mechanisms that have the included attributes.
 910    Future work within the Kitten working group is expected to
 911    standardize common attributes that SPNEGO mechanisms may wish to
 912    support.  At this time it is sufficient to say that initiators MAY
 913    include OIDs that do not correspond to mechanisms.  Such OIDs MAY
 914    influence the acceptor's choice of mechanism.  As discussed in
 915    Section 5, if there are mechanisms that if present in the initiator's
 916    list of mechanisms might be preferred by the acceptor to the
 917    initiator's preferred mechanism, the acceptor MUST demand the MIC
 918    token exchange.  As the consequence, acceptors MUST demand the MIC
 919    token exchange if they support negotiation of attributes not
 920    available in the initiator's preferred mechanism regardless of
 921    whether the initiator actually requested these attributes.
 922
 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 Zhu, et al.               Expires July 27, 2005                [Page 17]
 951 \f
 952 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
 953
 954
 955 7.  Security Considerations
 956
 957    In order to produce the MIC token for the mechanism list, the
 958    mechanism must provide integrity protection.  When the selected
 959    mechanism does not support integrity protection, the negotiation is
 960    vulnerable: an active attacker can force it to use a security
 961    mechanism that is not mutually preferred but is acceptable to the
 962    target.
 963
 964    This protocol provides the following guarantees when per-message
 965    integrity services are available on the established mechanism context
 966    and the mechanism list was altered by an adversary such that a
 967    mechanism which is not mutually preferred could be selected:
 968
 969    a) If the last mechanism token is sent by the initiator, both peers
 970       shall fail;
 971    b) If the last mechanism token is sent by the acceptor, the acceptor
 972       shall not complete and the initiator at worst shall complete with
 973       its preferred mechanism being selected.
 974
 975    The negotiation may not be terminated if an alteration was made but
 976    it had no material impact.
 977
 978    The protection of the negotiation depends on the strength of the
 979    integrity protection.  In particular, the strength of SPNEGO is no
 980    stronger than the integrity protection of the weakest mechanism
 981    acceptable to GSS-API peers.
 982
 983    Note that where there exist multiple mechanisms with similar context
 984    tokens, but different semantics, such that some or all of the
 985    mechanisms' context tokens can be easily altered so that one
 986    mechanism's context tokens may pass for another of the similar
 987    mechanism's context tokens, then there may exist downgrade or similar
 988    attacks.  For example, if a given family of mechanisms uses the same
 989    context token syntax for two or more variants and depends on the OID
 990    in the initial token's pseudo-ASN.1/DER wrapper, but does not provide
 991    integrity protection for that OID, then there may exist an attack
 992    against those mechanisms.  SPNEGO does not generally defeat such
 993    attacks.
 994
 995    In all cases, the communicating peers are exposed to the denial of
 996    service threat.
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006 Zhu, et al.               Expires July 27, 2005                [Page 18]
1007 \f
1008 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1009
1010
1011 8.  IANA Considerations
1012
1013    This document has no actions for IANA.
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062 Zhu, et al.               Expires July 27, 2005                [Page 19]
1063 \f
1064 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1065
1066
1067 9.  Acknowledgments
1068
1069    The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
1070    Martin Rex, Jeff Altman, Tom Yu, Cristian Ilac, Simon Spero and Bill
1071    Sommerfeld for their comments and suggestions during development of
1072    this document.
1073
1074    Luke Howard provided a prototype of this protocol in Heimdal and
1075    resolved several issues in the initial draft.
1076
1077    Eric Baize and Denis Pinkas wrote the original SPNEGO specification
1078    [RFC2478] of which some of the text has been retained in this
1079    document.
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118 Zhu, et al.               Expires July 27, 2005                [Page 20]
1119 \f
1120 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1121
1122
1123 10.  References
1124
1125 10.1  Normative References
1126
1127    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1128               Requirement Levels", BCP 14, RFC 2119, March 1997.
1129
1130    [RFC2743]  Linn, J., "Generic Security Service Application Program
1131               Interface Version 2, Update 1", RFC 2743, January 2000.
1132
1133    [X690]     ASN.1 encoding rules: Specification of Basic Encoding
1134               Rules (BER), Canonical Encoding Rules (CER) and
1135               Distinguished Encoding Rules (DER), ITU-T Recommendation
1136               X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
1137
1138 10.2  Informative References
1139
1140    [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
1141               Negotiation Mechanism", RFC 2478, December 1998.
1142
1143
1144 Authors' Addresses
1145
1146    Larry Zhu
1147    Microsoft Corporation
1148    One Microsoft Way
1149    Redmond, WA  98052
1150    US
1151
1152    Email: lzhu@microsoft.com
1153
1154
1155    Paul Leach
1156    Microsoft Corporation
1157    One Microsoft Way
1158    Redmond, WA  98052
1159    US
1160
1161    Email: paulle@microsoft.com
1162
1163
1164    Karthik Jaganathan
1165    Microsoft Corporation
1166    One Microsoft Way
1167    Redmond, WA  98052
1168    US
1169
1170    Email: karthikj@microsoft.com
1171
1172
1173
1174
1175 Zhu, et al.               Expires July 27, 2005                [Page 21]
1176 \f
1177 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1178
1179
1180    Wyllys Ingersoll
1181    Sun Microsystems
1182    1775 Wiehle Avenue, 2nd Floor
1183    Reston, VA  20190
1184    US
1185
1186    Email: wyllys.ingersoll@sun.com
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231 Zhu, et al.               Expires July 27, 2005                [Page 22]
1232 \f
1233 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1234
1235
1236 Appendix A.  SPNEGO ASN.1 Module
1237
1238        SPNEGOASNOneSpec {
1239           iso(1) identified-organization(3) dod(6) internet(1)
1240           security(5) mechanism(5) snego (2) modules(4) spec2(2)
1241        } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1242
1243        MechType ::= OBJECT IDENTIFIER
1244            -- OID represents each security mechanism as suggested by
1245            -- [RFC2743]
1246
1247        MechTypeList ::= SEQUENCE OF MechType
1248
1249        NegotiationToken ::= CHOICE {
1250            negTokenInit    [0] NegTokenInit,
1251            negTokenResp    [1] NegTokenResp
1252        }
1253
1254        NegTokenInit ::= SEQUENCE {
1255            mechTypes       [0] MechTypeList,
1256            reqFlags        [1] ContextFlags  OPTIONAL,
1257              -- inherited from RFC 2478 for backward compatibility,
1258              -- RECOMMENDED to be left out
1259            mechToken       [2] OCTET STRING  OPTIONAL,
1260            mechListMIC     [3] OCTET STRING  OPTIONAL,
1261            ...
1262        }
1263        NegTokenResp ::= SEQUENCE {
1264            negState       [0] ENUMERATED {
1265                accept-completed    (0),
1266                accept-incomplete   (1),
1267                reject              (2),
1268                request-mic         (3)
1269            }                                 OPTIONAL,
1270              -- REQUIRED in the first reply from the target
1271            supportedMech   [1] MechType      OPTIONAL,
1272              -- present only in the first reply from the target
1273            responseToken   [2] OCTET STRING  OPTIONAL,
1274            mechListMIC     [3] OCTET STRING  OPTIONAL,
1275            ...
1276        }
1277
1278        ContextFlags ::= BIT STRING {
1279            delegFlag       (0),
1280            mutualFlag      (1),
1281            replayFlag      (2),
1282            sequenceFlag    (3),
1283            anonFlag        (4),
1284
1285
1286
1287 Zhu, et al.               Expires July 27, 2005                [Page 23]
1288 \f
1289 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1290
1291
1292            confFlag        (5),
1293            integFlag       (6)
1294        } (SIZE (32))
1295
1296        END
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343 Zhu, et al.               Expires July 27, 2005                [Page 24]
1344 \f
1345 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1346
1347
1348 Appendix B.  GSS-API Negotiation Support API
1349
1350    In order to provide to a GSS-API caller (either the initiator or the
1351    target or both) the ability to choose among the set of supported
1352    mechanisms a reduced set of mechanisms for negotiation, two
1353    additional APIs are defined:
1354
1355    o  GSS_Get_neg_mechs() indicates the set of security mechanisms
1356       available on the local system to the caller for negotiation, for
1357       which appropriate credentials are available.
1358    o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
1359       used on the local system by the caller for negotiation, for the
1360       given credentials.
1361
1362 B.1  GSS_Set_neg_mechs call
1363
1364    Inputs:
1365
1366    o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
1367       -- credentials
1368    o  mech_set SET OF OBJECT IDENTIFIER
1369
1370    Outputs:
1371
1372    o  major_status INTEGER,
1373    o  minor_status INTEGER
1374
1375    Return major_status codes:
1376
1377    o  GSS_S_COMPLETE indicates that the set of security mechanisms
1378       available for negotiation has been set to mech_set.
1379    o  GSS_S_FAILURE indicates that the requested operation could not be
1380       performed for reasons unspecified at the GSS-API level.
1381
1382    Allows callers to specify the set of security mechanisms that may be
1383    negotiated with the credential identified by cred_handle.  This call
1384    is intended for support of specialized callers who need to restrict
1385    the set of negotiable security mechanisms from the set of all
1386    security mechanisms available to the caller (based on available
1387    credentials).  Note that if more than one mechanism is specified in
1388    mech_set, the order in which those mechanisms are specified implies a
1389    relative preference.
1390
1391 B.2  GSS_Get_neg_mechs call
1392
1393    Input:
1394
1395
1396
1397
1398
1399 Zhu, et al.               Expires July 27, 2005                [Page 25]
1400 \f
1401 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1402
1403
1404    o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
1405       -- credentials
1406
1407    Outputs:
1408
1409    o  major_status INTEGER,
1410    o  minor_status INTEGER,
1411    o  mech_set SET OF OBJECT IDENTIFIER
1412
1413    Return major_status codes:
1414
1415    o  GSS_S_COMPLETE indicates that the set of security mechanisms
1416       available for negotiation has been returned in mech_set.
1417    o  GSS_S_FAILURE indicates that the requested operation could not be
1418       performed for reasons unspecified at the GSS-API level.
1419
1420    Allows callers to determine the set of security mechanisms available
1421    for negotiation with the credential identified by cred_handle.  This
1422    call is intended for support of specialized callers who need to
1423    reduce the set of negotiable security mechanisms from the set of
1424    supported security mechanisms available to the caller (based on
1425    available credentials).
1426
1427    Note: The GSS_Indicate_mechs() function indicates the full set of
1428    mechanism types available on the local system.  Since this call has
1429    no input parameter, the returned set is not necessarily available for
1430    all credentials.
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455 Zhu, et al.               Expires July 27, 2005                [Page 26]
1456 \f
1457 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1458
1459
1460 Appendix C.  Changes since RFC2478
1461
1462       SPNEGO implementations in Microsoft Windows 2000/Windows
1463       XP/Windows Server 2003 have the following behavior: no mechlistMIC
1464       is produced and mechlistMIC is not processed if one is provided;
1465       if the initiator sends the last mechanism token, the acceptor will
1466       send back a negotiation token with an accept_complete state and no
1467       mechlistMIC token.  In addition, an incorrect OID
1468       (1.2.840.48018.1.2.2) can be used to identify the GSS-API Kerberos
1469       Version 5 mechanism.
1470
1471       The following changes have been made to be compatible with these
1472       legacy implementations.
1473
1474       *  NegTokenTarg is changed to negTokenResp and it is the message
1475          format for all subsequent negotiation tokens.
1476       *  NegTokenInit is the message for the initial negotiation message
1477          and that message only.
1478       *  mechTypes in negTokenInit is not optional.
1479       *  If the selected mechanism is also the most preferred mechanism
1480          for both peers, it is safe to omit the MIC tokens.
1481
1482       If at least one of the two peers implements the updated pseudo
1483       mechanism in this document, the negotiation is protected.
1484
1485       The following changes are to address problems in RFC 2478.
1486
1487       *  reqFlags is not protected therefore it should not impact the
1488          negotiation.
1489       *  DER encoding is required.
1490       *  GSS_GetMIC() input is clarified.
1491       *  Per-message integrity services are requested for the negotiated
1492          mechanism.
1493       *  Two MIC tokens are exchanged, one in each direction.
1494
1495    An implementation that conforms to this specification will not
1496    inter-operate with a strict 2748 implementation.  Even if the new
1497    implementation always sends a mechlistMIC token, it will still fail
1498    to inter-operate.  If it is a server, it will fail because it
1499    requests a mechlistMIC token using an option that older
1500    implementations simply do not support.  Clients will tend to fail as
1501    well.
1502
1503    As an alternative to the approach chosen in this specification, we
1504    could have documented a correct behavior that is fully backward
1505    compatible with RFC 2478 and included an appendix on how to
1506    inter-operate with existing incorrect implementations of RFC 2478.
1507
1508
1509
1510
1511 Zhu, et al.               Expires July 27, 2005                [Page 27]
1512 \f
1513 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1514
1515
1516    As a practical matter, the SPNEGO implementers within the IETF have
1517    valued interoperability with the Microsoft implementations.  We were
1518    unable to choose to maintain reasonable security guarantees, maintain
1519    interoperability with the Microsoft implementations and maintain
1520    interoperability with correct implementations of RFC 2478.  The
1521    working group was not aware of any RFC 2478 implementations deployed
1522    on the Internet.  Even if there are such implementations, it is
1523    unlikely that they will inter-operate because of a critical flaw in
1524    the description of the encoding of the mechanism list in RFC 2478.
1525
1526    With the approach taken in this specification, security is ensured
1527    between new implementations all the time while maintaining
1528    interoperability with the implementations deployed within the IETF
1529    community.  The working group believes that this justifies breaking
1530    compatibility with a correct implementation of RFC 2478.
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567 Zhu, et al.               Expires July 27, 2005                [Page 28]
1568 \f
1569 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1570
1571
1572 Appendix D.  mechListMIC Computation Example
1573
1574    The following is an example to illustrate how the mechListMIC field
1575    would be computed.
1576
1577    The initial part of the DER encoding of NegTokenInit is constructed
1578    as follows (the "nn" are length encodings, possibly longer than one
1579    octet):
1580
1581       30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
1582       nn -- length
1583
1584          -- contents octets of the SEQUENCE begin with
1585          -- DER encoding of "[0] MechTypeList":
1586          A0 -- identifier octet for constructed [0]
1587          nn -- length
1588
1589              -- contents of the constructed [0] are DER encoding
1590              -- of MechTypeList (which is a SEQUENCE):
1591              30 -- identifier octet for constructed SEQUENCE
1592              nn -- length
1593
1594                 -- contents octets of the SEQUENCE begin with
1595                 -- DER encoding of OBJECT IDENTIFIER:
1596                 06 -- identifier octet for primitive OBJECT IDENTIFIER
1597                 09 -- length
1598                 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
1599                                            -- {1 2 840 113554 1 2 2}
1600
1601    If a mechlistMIC needs to be generated (according to the rules in
1602    Section 5), it is computed by using the DER encoding of the type
1603    MechTypeList data from the initiator's NegTokenInit token as input to
1604    the GSS_GetMIC() function.  In this case, the MIC would be computed
1605    over the following octets:
1606
1607       DER encoding of MechTypeList:
1608       30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
1609
1610    Note that the identifier octet and length octet(s) for constructed
1611    [0] (A0 nn) are not included in the MIC computation.
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623 Zhu, et al.               Expires July 27, 2005                [Page 29]
1624 \f
1625 Internet-Draft        GSS-API Negotiation Mechanism         January 2005
1626
1627
1628 Intellectual Property Statement
1629
1630    The IETF takes no position regarding the validity or scope of any
1631    Intellectual Property Rights or other rights that might be claimed to
1632    pertain to the implementation or use of the technology described in
1633    this document or the extent to which any license under such rights
1634    might or might not be available; nor does it represent that it has
1635    made any independent effort to identify any such rights.  Information
1636    on the procedures with respect to rights in RFC documents can be
1637    found in BCP 78 and BCP 79.
1638
1639    Copies of IPR disclosures made to the IETF Secretariat and any
1640    assurances of licenses to be made available, or the result of an
1641    attempt made to obtain a general license or permission for the use of
1642    such proprietary rights by implementers or users of this
1643    specification can be obtained from the IETF on-line IPR repository at
1644    http://www.ietf.org/ipr.
1645
1646    The IETF invites any interested party to bring to its attention any
1647    copyrights, patents or patent applications, or other proprietary
1648    rights that may cover technology that may be required to implement
1649    this standard.  Please address the information to the IETF at
1650    ietf-ipr@ietf.org.
1651
1652
1653 Disclaimer of Validity
1654
1655    This document and the information contained herein are provided on an
1656    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1657    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1658    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1659    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1660    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1661    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1662
1663
1664 Copyright Statement
1665
1666    Copyright (C) The Internet Society (2005).  This document is subject
1667    to the rights, licenses and restrictions contained in BCP 78, and
1668    except as set forth therein, the authors retain all their rights.
1669
1670
1671 Acknowledgment
1672
1673    Funding for the RFC Editor function is currently provided by the
1674    Internet Society.
1675
1676
1677
1678
1679 Zhu, et al.               Expires July 27, 2005                [Page 30]
1680 \f