doc/specifications/draft-jaganathan-win-krb-authz-00.txt

   1
   2
   3
   4 Internet Engineering Task Force                            K. Jaganathan
   5 Internet-Draft                                                    L. Zhu
   6 EDocument: draft-jaganathan-win-krb-authz-00.txt                J. Brezak
   7 Category: Informational                            Microsoft Corporation
   8 Expires: January 8, 2006                                    July 7, 2005
   9
  10
  11              Windows Authorization Data in Kerberos Tickets
  12                  draft-jaganathan-win-krb-authz-00.txt
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37    This Internet-Draft will expire on January 8, 2006.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2005).
  42
  43 Abstract
  44
  45    Microsoft Windows 2000 includes operating system specific data in the
  46    Kerberos V5  authorization data field that is used for access
  47    control.  This data is used to create an NT access token.  The access
  48    token is used by the system to enforce access checking when
  49    attempting to access objects.  This document describes the structure
  50    of the Windows 2000 specific authorization data that is carried in
  51    that field for use by servers in performing access control.
  52
  53
  54
  55 Jaganathan, et al.       Expires January 8, 2006                [Page 1]
  56 \f
  57 Internet-Draft         Windows Authorization Data              July 2005
  58
  59
  60 Table of Contents
  61
  62    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
  63    2.   Conventions Used in This Document  . . . . . . . . . . . . .   4
  64    3.   Top-Level PAC Structure  . . . . . . . . . . . . . . . . . .   5
  65    4.   PAC Credential Information (PAC_LOGON_INFO)  . . . . . . . .   7
  66    5.   Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM)  .  11
  67    6.   PAC Request Pre-Auth Data  . . . . . . . . . . . . . . . . .  12
  68    7.   Security Considerations  . . . . . . . . . . . . . . . . . .  13
  69    8.   Normative References . . . . . . . . . . . . . . . . . . . .  13
  70         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  13
  71         Intellectual Property and Copyright Statements . . . . . . .  15
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Jaganathan, et al.       Expires January 8, 2006                [Page 2]
 112 \f
 113 Internet-Draft         Windows Authorization Data              July 2005
 114
 115
 116 1.  Introduction
 117
 118    The Microsoft Windows  implementation of Kerberos uses the
 119    authorization data field in the ticket to carry Windows
 120    authorization.  This authorization data is then used by servers to
 121    enforce access control when the user accesses a resource.  The
 122    authorization data includes Security Identifiers (SIDs) which
 123    represent a user's Windows groups
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Jaganathan, et al.       Expires January 8, 2006                [Page 3]
 168 \f
 169 Internet-Draft         Windows Authorization Data              July 2005
 170
 171
 172 2.  Conventions Used in This Document
 173
 174    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 175    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 176    document are to be interpreted as described in [RFC2119].
 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
 223 Jaganathan, et al.       Expires January 8, 2006                [Page 4]
 224 \f
 225 Internet-Draft         Windows Authorization Data              July 2005
 226
 227
 228 3.  Top-Level PAC Structure
 229
 230    The PAC is generated by the KDC under the following conditions:
 231
 232         o  during an AS request that has been validated with pre-
 233            authentication
 234         o during a TGS request when the client has no PAC and the target
 235            is a service in the domain or a ticket granting service
 236            (referral ticket).
 237
 238    The PAC itself is included in the IF-RELEVANT (ID 1) portion of the
 239    authorization data in a ticket.  Within the IF-RELEVANT portion, it
 240    is encoded KERB_AUTH_DATA_PAC with ID 128.
 241
 242    The PAC is defined as a C data type, with integers encoded in little-
 243    endian order.  The PAC itself is made up of several layers.  The
 244    outer structure, contained directly in the authorization data, is as
 245    follows.  The top-level structure is the PACTYPE structure:
 246
 247            typedef unsigned long ULONG;
 248            typedef unsigned short USHORT;
 249            typedef unsigned long64 ULONG64;
 250            typedef unsigned char UCHAR;
 251
 252            typedef struct _PACTYPE {
 253                ULONG cBuffers;
 254                ULONG Version;
 255                PAC_INFO_BUFFER Buffers[1];
 256            } PACTYPE;
 257
 258      The fields are defined as follows:
 259      cBuffers - contains the number of entries in the array Buffers
 260      Version - this is version zero
 261      Buffers - contains a conformant array of PAC_INFO_BUFFER structures
 262
 263    The PAC_INFO_BUFFER structure contains information about each piece
 264    of the PAC.
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279 Jaganathan, et al.       Expires January 8, 2006                [Page 5]
 280 \f
 281 Internet-Draft         Windows Authorization Data              July 2005
 282
 283
 284       typedef struct _PAC_INFO_BUFFER {
 285                ULONG ulType;
 286                ULONG cbBufferSize;
 287                ULONG64 Offset;
 288            } PAC_INFO_BUFFER;
 289
 290       Type fields are defined as follows:
 291
 292       ulType - contains the type of data contained in this buffer. For
 293               Windows 2000 access control, it may be one of the
 294               following, which are explained further below:
 295
 296               #define PAC_LOGON_INFO               1
 297               #define PAC_SERVER_CHECKSUM          6
 298               #define PAC_PRIVSVR_CHECKSUM         7
 299
 300     Offset - contains the offset to the beginning of the data, in bytes,
 301              from the beginning of the PACTYPE structure. The data
 302              offset must by a multiple of 8. If the data pointed to by
 303              this field is complex, the data is typically NDR encoded.
 304              If the data is simple (indicating it includes no pointer
 305              types or complex structures) it is a little-endian format
 306              data structure.
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335 Jaganathan, et al.       Expires January 8, 2006                [Page 6]
 336 \f
 337 Internet-Draft         Windows Authorization Data              July 2005
 338
 339
 340 4.  PAC Credential Information (PAC_LOGON_INFO)
 341
 342    PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential
 343    information for the client of the Kerberos ticket.  The data itself
 344    is contained in a KERB_VALIDATION_INFO structure, which is NDR
 345    encoded.  The output of the NDR encoding is placed in the
 346    PAC_INFO_BUFFER structure of type PAC_LOGON_INFO.
 347
 348        typedef struct _KERB_VALIDATION_INFO {
 349                FILETIME Reserved0;
 350                FILETIME Reserved1;
 351                FILETIME KickOffTime;
 352                FILETIME Reserved2;
 353                FILETIME Reserved3;
 354                FILETIME Reserved4;
 355                UNICODE_STRING Reserved5;
 356                UNICODE_STRING Reserved6;
 357                UNICODE_STRING Reserved7;
 358                UNICODE_STRING Reserved8;
 359                UNICODE_STRING Reserved9;
 360                UNICODE_STRING Reserved10;
 361                USHORT Reserved11;
 362                USHORT Reserved12;
 363                ULONG UserId;
 364                ULONG PrimaryGroupId;
 365                ULONG GroupCount;
 366                [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
 367                ULONG UserFlags;
 368                ULONG Reserved13[4];
 369                UNICODE_STRING Reserved14;
 370                UNICODE_STRING Reserved15;
 371                PSID LogonDomainId;
 372                ULONG Reserved16[2];
 373                ULONG Reserved17;
 374                ULONG Reserved18[7];
 375                ULONG SidCount;
 376                [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
 377                PSID ResourceGroupDomainSid;
 378                ULONG ResourceGroupCount;
 379                [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP
 380            ResourceGroupIds;
 381            } KERB_VALIDATION_INFO;
 382      Reserved fields are not defined in this document and are not used
 383      in the construction of access control tokens.
 384
 385       The fields are defined as follows:
 386       KickOffTime - the time at which the server should forcibly
 387               logoff the client. If the client should not be forced off,
 388
 389
 390
 391 Jaganathan, et al.       Expires January 8, 2006                [Page 7]
 392 \f
 393 Internet-Draft         Windows Authorization Data              July 2005
 394
 395
 396               this field should be set to (0x7fffffff,0xffffffff). If a
 397               kickoff time is to be enforced, the service ticket
 398               lifetime will never exceed this value.
 399       UserId - This field contains the relative Id for the client. If
 400               zero, then the User ID is the first SID in the ExtraSids
 401               field.
 402       PrimaryGroupId - This field contains the relative ID for this
 403               client's primary group.
 404       GroupCount - This field contains the number of groups, within the
 405               client's domain, to which the client is a member.
 406       GroupIds - This field contains an array of the relative Ids and
 407               attributes of the groups in the client's domain of which
 408               the client is a member.
 409       UserFlags - This field contains information about which fields in
 410               this structure are valid. The two bits that may be set are
 411               indicated below. Having these flags set indicates that the
 412               corresponding fields in the KERB_VALIDATION_INFO structure
 413               are present and valid.
 414
 415               #define LOGON_EXTRA_SIDS             0x0020
 416               #define LOGON_RESOURCE_GROUPS        0x0200
 417
 418       LogonDomainId - This field contains the SID of the clients domain.
 419               This field is used in conjunction with the UserId,
 420               PrimaryGroupId,and GroupIds fields to create the user and
 421               group SIDs for the client.
 422       SidCount - This field contains the number of SIDs present in the
 423               ExtraSids field. This field is only valid if the
 424               LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
 425       ExtraSids - This field contains a list of SIDs for groups to which
 426               the user is a member. This field is only valid if the
 427               LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
 428       ResouceGroupCount - This field contains the number of resource
 429               groups in the ResourceGroupIds field. This field is only
 430               valid if the LOGON RESOURCE_GROUPS flag has been set in
 431               the UserFlags field._
 432       ResourceGroupDomainSid - This field contains the SID of the
 433               resource domain. This field is used in conjunction with
 434               the ResourceGroupIds field to create the group SIDs for
 435               the client.
 436       ResourceGroupIds - This field contains an array of the relative
 437               Ids and attributes of the groups in the resource domain of
 438               which the resource is a member.
 439
 440       When used in the KERB_VALIDATION_INFO, this is NDR encoded. The
 441       FILETIME type is defined as follows:
 442
 443            typedef unsigned int DWORD;
 444
 445
 446
 447 Jaganathan, et al.       Expires January 8, 2006                [Page 8]
 448 \f
 449 Internet-Draft         Windows Authorization Data              July 2005
 450
 451
 452            typedef struct _FILETIME {
 453                DWORD dwLowDateTime;
 454                DWORD dwHighDateTime;
 455            } FILETIME;
 456
 457       Times are encoded as the number of 100 nanosecond increments since
 458       January 1, 1601, in UTC time.
 459
 460       When used in the KERB_VALIDATION_INFO, this is NDR encoded. The
 461       UNICODE_STRING structure is defined as:
 462
 463            typedef struct _UNICODE_STRING
 464                USHORT Length;
 465                USHORT MaximumLength;
 466                [size_is(MaximumLength / 2), length_is((Length) / 2) ]
 467            USHORT *  Buffer;
 468            } UNICODE_STRING;
 469
 470       The Length field contains the number of bytes in the string, not
 471       including the null terminator, and the MaximumLength field
 472       contains the total number of bytes in the buffer containing the
 473       string.
 474
 475       The GROUP_MEMBERSHIP structure contains the relative ID of a group
 476       and the corresponding attributes for the group.
 477
 478            typedef struct _GROUP_MEMBERSHIP {
 479                ULONG RelativeId;
 480                ULONG Attributes;
 481            } *PGROUP_MEMBERSHIP;
 482
 483       The group attributes must be:
 484
 485            #define SE_GROUP_MANDATORY              (0x00000001L)
 486            #define SE_GROUP_ENABLED_BY_DEFAULT     (0x00000002L)
 487            #define SE_GROUP_ENABLED                (0x00000004L)
 488
 489       The SID structure is defined as follows:
 490
 491
 492            typedef struct _SID_IDENTIFIER_AUTHORITY {
 493                UCHAR Value[6];
 494            } SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY;
 495
 496       The constant value for the NT Authority is
 497
 498            #define SECURITY_NT_AUTHORITY           {0,0,0,0,0,5}
 499
 500
 501
 502
 503 Jaganathan, et al.       Expires January 8, 2006                [Page 9]
 504 \f
 505 Internet-Draft         Windows Authorization Data              July 2005
 506
 507
 508            typedef struct _SID {
 509               UCHAR Revision;
 510               UCHAR SubAuthorityCount;
 511               SID_IDENTIFIER_AUTHORITY IdentifierAuthority;
 512               [size_is(SubAuthorityCount)] ULONG SubAuthority[*];
 513            } SID, *PSID;
 514
 515       Other authorities are defined in the Microsoft Developer Network
 516       Development Kit 3.
 517       The SubAuthorityCount field contains the number of elements in the
 518       actual SubAuthority conformant array. The maximum number of
 519       subauthorities allowed is 15.
 520
 521       The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs
 522       and their corresponding attributes:
 523
 524            typedef struct _KERB_SID_AND_ATTRIBUTES {
 525                PSID Sid;
 526                ULONG Attributes;
 527            } KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES;
 528
 529       The attributes are the same as the group attributes defined above.
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559 Jaganathan, et al.       Expires January 8, 2006               [Page 10]
 560 \f
 561 Internet-Draft         Windows Authorization Data              July 2005
 562
 563
 564 5.  Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM)
 565
 566    The PAC contains two digital signatures: one using the key of the
 567    server, and one using the key of the KDC.  The signatures are present
 568    for two reasons.  First, the signature with the server's key is
 569    present to prevent a client from generating their own PAC and sending
 570    it to the KDC as encrypted authorization data to be included in
 571    tickets.  Second, the signature with the KDC's key is present to
 572    prevent an untrusted service from forging a ticket to itself with an
 573    invalid PAC.  The two signatures are sent in PAC_INFO_BUFFERs of type
 574    PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM respectively.
 575
 576            The signatures are contained in the following structure:
 577
 578            typedef struct _PAC_SIGNATURE_DATA {
 579                ULONG SignatureType;
 580                UCHAR Signature[1];
 581            } PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA;
 582
 583       The fields are defined as follows:
 584
 585       SignatureType - This field contains the type of checksum used to
 586               create a signature. The checksum must be a keyed checksum.
 587
 588       Signature - This field consists of an array of bytes containing
 589               the checksum data. The length of bytes may be determined
 590               by the wrapping PAC_INFO_BUFFER structure.
 591
 592       For the server's checksum, the key used to generate the signature
 593       should be the same key used to encrypt the ticket. Thus, if the
 594       enc_tkt_in_skey option is used, the session key from the server's
 595       TGT should be used. The Key used to encrypt ticket granting
 596       tickets is used to generate the KDC's checksum.
 597
 598       The checksums are computed as follows:
 599
 600         1. The complete PAC is built, including space for both checksums
 601         2. The data portion of both checksums is zeroed.
 602         3. The entire PAC structure is checksummed with the server's key
 603            and the result is stored in the server's checksum structure.
 604         4. The server's checksum is then checksummed with the KDC's key.
 605         5. The checksum with the KDC key is stored in the KDC's checksum
 606            structure.
 607
 608
 609
 610
 611
 612
 613
 614
 615 Jaganathan, et al.       Expires January 8, 2006               [Page 11]
 616 \f
 617 Internet-Draft         Windows Authorization Data              July 2005
 618
 619
 620 6.  PAC Request Pre-Auth Data
 621
 622    Normally, the PAC is included in every pre-authenticated ticket
 623    received from an AS request.  However, a client may also explicitly
 624    request either to include or to not include the PAC.  This is done by
 625    sending the PAC-REQUEST preauth data.
 626
 627            This is an ASN.1 encoded structure.
 628
 629            KERB-PA-PAC-REQUEST     ::= SEQUENCE {
 630                   include-pac[0] BOOLEAN -- if TRUE, and no pac present,
 631                                          -- include PAC.
 632                                          ---If FALSE, and pac
 633                                          -- PAC present, remove PAC
 634            }
 635
 636       The fields are defined as follows:
 637
 638      include-pac - This field indicates whether a PAC should be included
 639              or not. If the value is TRUE, a PAC will be included
 640              independent of other preauth data. If the value is FALSE,
 641              then no PAC will be included, even if other preauth data is
 642              present.
 643
 644       The preauth ID is:
 645            #define KRB5_PADATA_PAC_REQUEST         128
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671 Jaganathan, et al.       Expires January 8, 2006               [Page 12]
 672 \f
 673 Internet-Draft         Windows Authorization Data              July 2005
 674
 675
 676 7.  Security Considerations
 677
 678    Before the PAC data is used for access control, the
 679    PAC_SERVER_CHECKSUM signature MUST be checked.  This will verify that
 680    the provider of the PAC data knows the server's secret key.
 681    Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL.  It is used to
 682    verify that the PAC was issued from the KDC and not placed in the
 683    ticket by someone other than the KDC with access to the service key.
 684
 685    Caution must be used with accepting the SIDs present in the logon-
 686    info part of the PAC.  Only SIDs from a domain that is authoritative
 687    for a particular domain's SIDs should be used in the construction of
 688    access tokens.  If a SID is found to be from outside of a domain's
 689    authoritative SID namespace, it MUST be ignored for purposes of
 690    access control.
 691
 692 8.  Normative References
 693
 694    [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
 695               Authentication Service (V5)", RFC 1510, September 1993.
 696
 697    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 698               Requirement Levels", BCP 14, RFC 2119, March 1997.
 699
 700
 701 Authors' Addresses
 702
 703    Karthik Jaganathan
 704    Microsoft Corporation
 705    One Microsoft Way
 706    Redmond, WA  98052
 707    US
 708
 709    Email: karthikj@microsoft.com
 710
 711
 712    Larry Zhu
 713    Microsoft Corporation
 714    One Microsoft Way
 715    Redmond, WA  98052
 716    US
 717
 718    Email: lzhu@microsoft.com
 719
 720
 721
 722
 723
 724
 725
 726
 727 Jaganathan, et al.       Expires January 8, 2006               [Page 13]
 728 \f
 729 Internet-Draft         Windows Authorization Data              July 2005
 730
 731
 732    John Brezak
 733    Microsoft Corporation
 734    One Microsoft Way
 735    Redmond, WA  98052
 736    US
 737
 738    Email: jbrezak@microsoft.com
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783 Jaganathan, et al.       Expires January 8, 2006               [Page 14]
 784 \f
 785 Internet-Draft         Windows Authorization Data              July 2005
 786
 787
 788 Intellectual Property Statement
 789
 790    The IETF takes no position regarding the validity or scope of any
 791    Intellectual Property Rights or other rights that might be claimed to
 792    pertain to the implementation or use of the technology described in
 793    this document or the extent to which any license under such rights
 794    might or might not be available; nor does it represent that it has
 795    made any independent effort to identify any such rights.  Information
 796    on the procedures with respect to rights in RFC documents can be
 797    found in BCP 78 and BCP 79.
 798
 799    Copies of IPR disclosures made to the IETF Secretariat and any
 800    assurances of licenses to be made available, or the result of an
 801    attempt made to obtain a general license or permission for the use of
 802    such proprietary rights by implementers or users of this
 803    specification can be obtained from the IETF on-line IPR repository at
 804    http://www.ietf.org/ipr.
 805
 806    The IETF invites any interested party to bring to its attention any
 807    copyrights, patents or patent applications, or other proprietary
 808    rights that may cover technology that may be required to implement
 809    this standard.  Please address the information to the IETF at
 810    ietf-ipr@ietf.org.
 811
 812
 813 Disclaimer of Validity
 814
 815    This document and the information contained herein are provided on an
 816    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 817    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 818    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 819    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 820    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 821    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 822
 823
 824 Copyright Statement
 825
 826    Copyright (C) The Internet Society (2005).  This document is subject
 827    to the rights, licenses and restrictions contained in BCP 78, and
 828    except as set forth therein, the authors retain all their rights.
 829
 830
 831 Acknowledgment
 832
 833    Funding for the RFC Editor function is currently provided by the
 834    Internet Society.
 835
 836
 837
 838
 839 Jaganathan, et al.       Expires January 8, 2006               [Page 15]
 840 \f
 841