source4/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt

   1 NETWORK WORKING GROUP                                            B. Tung
   2 Internet-Draft                        USC Information Sciences Institute
   3 Expires: January 20, 2006                                         L. Zhu
   4                                                    Microsoft Corporation
   5                                                            July 19, 2005
   6
   7
   8      Public Key Cryptography for Initial Authentication in Kerberos
   9                    draft-ietf-cat-kerberos-pk-init-27
  10
  11 Status of this Memo
  12
  13    By submitting this Internet-Draft, each author represents that any
  14    applicable patent or other IPR claims of which he or she is aware
  15    have been or will be disclosed, and any of which he or she becomes
  16    aware will be disclosed, in accordance with Section 6 of BCP 79.
  17
  18    Internet-Drafts are working documents of the Internet Engineering
  19    Task Force (IETF), its areas, and its working groups.  Note that
  20    other groups may also distribute working documents as Internet-
  21    Drafts.
  22
  23    Internet-Drafts are draft documents valid for a maximum of six months
  24    and may be updated, replaced, or obsoleted by other documents at any
  25    time.  It is inappropriate to use Internet-Drafts as reference
  26    material or to cite them other than as "work in progress."
  27
  28    The list of current Internet-Drafts can be accessed at
  29    http://www.ietf.org/ietf/1id-abstracts.txt.
  30
  31    The list of Internet-Draft Shadow Directories can be accessed at
  32    http://www.ietf.org/shadow.html.
  33
  34    This Internet-Draft will expire on January 20, 2006.
  35
  36 Copyright Notice
  37
  38    Copyright (C) The Internet Society (2005).
  39
  40 Abstract
  41
  42    This document describes protocol extensions (hereafter called PKINIT)
  43    to the Kerberos protocol specification.  These extensions provide a
  44    method for integrating public key cryptography into the initial
  45    authentication exchange, by using asymmetric-key signature and/or
  46    encryption algorithms in pre-authentication data fields.
  47
  48
  49
  50
  51
  52 Tung & Zhu              Expires January 20, 2006                [Page 1]
  53 \f
  54 Internet-Draft                   PKINIT                        July 2005
  55
  56
  57 Table of Contents
  58
  59    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  60    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
  61    3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  62      3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
  63        3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
  64        3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
  65        3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
  66      3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
  67        3.2.1   Generation of Client Request . . . . . . . . . . . . .  7
  68        3.2.2   Receipt of Client Request  . . . . . . . . . . . . . . 10
  69        3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 14
  70        3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
  71      3.3   Interoperability Requirements  . . . . . . . . . . . . . . 20
  72      3.4   KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
  73    4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
  74    5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
  75    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
  76    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
  77      7.1   Normative References . . . . . . . . . . . . . . . . . . . 23
  78      7.2   Informative References . . . . . . . . . . . . . . . . . . 24
  79        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
  80    A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 25
  81        Intellectual Property and Copyright Statements . . . . . . . . 31
  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 Tung & Zhu              Expires January 20, 2006                [Page 2]
 109 \f
 110 Internet-Draft                   PKINIT                        July 2005
 111
 112
 113 1.  Introduction
 114
 115    A client typically authenticates itself to a service in Kerberos
 116    using three distinct though related exchanges.  First, the client
 117    requests a ticket-granting ticket (TGT) from the Kerberos
 118    authentication server (AS).  Then, it uses the TGT to request a
 119    service ticket from the Kerberos ticket-granting server (TGS).
 120    Usually, the AS and TGS are integrated in a single device known as a
 121    Kerberos Key Distribution Center, or KDC.  Finally, the client uses
 122    the service ticket to authenticate itself to the service.
 123
 124    The advantage afforded by the TGT is that the client exposes his
 125    long-term secrets only once.  The TGT and its associated session key
 126    can then be used for any subsequent service ticket requests.  One
 127    result of this is that all further authentication is independent of
 128    the method by which the initial authentication was performed.
 129    Consequently, initial authentication provides a convenient place to
 130    integrate public-key cryptography into Kerberos authentication.
 131
 132    As defined in [RFC4120], Kerberos authentication exchanges use
 133    symmetric-key cryptography, in part for performance.  One
 134    disadvantage of using symmetric-key cryptography is that the keys
 135    must be shared, so that before a client can authenticate itself, he
 136    must already be registered with the KDC.
 137
 138    Conversely, public-key cryptography (in conjunction with an
 139    established Public Key Infrastructure) permits authentication without
 140    prior registration with a KDC.  Adding it to Kerberos allows the
 141    widespread use of Kerberized applications by clients without
 142    requiring them to register first with a KDC--a requirement that has
 143    no inherent security benefit.
 144
 145    As noted above, a convenient and efficient place to introduce public-
 146    key cryptography into Kerberos is in the initial authentication
 147    exchange.  This document describes the methods and data formats for
 148    integrating public-key cryptography into Kerberos initial
 149    authentication.
 150
 151 2.  Conventions Used in This Document
 152
 153    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 154    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 155    document are to be interpreted as described in [RFC2119].
 156
 157    Both the AS and the TGS are referred to as the KDC.
 158
 159    In this document, the encryption key used to encrypt the enc-part
 160    field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
 161
 162
 163
 164 Tung & Zhu              Expires January 20, 2006                [Page 3]
 165 \f
 166 Internet-Draft                   PKINIT                        July 2005
 167
 168
 169    reply key.
 170
 171 3.  Extensions
 172
 173    This section describes extensions to [RFC4120] for supporting the use
 174    of public-key cryptography in the initial request for a ticket.
 175
 176    Briefly, this document defines the following extensions to [RFC4120]:
 177
 178    1. The client indicates the use of public-key authentication by
 179       including a special preauthenticator in the initial request.  This
 180       preauthenticator contains the client's public-key data and a
 181       signature.
 182
 183    2. The KDC tests the client's request against its authentication
 184       policy and trusted Certification Authorities (CAs).
 185
 186    3. If the request passes the verification tests, the KDC replies as
 187       usual, but the reply is encrypted using either:
 188
 189       a. a key generated through a Diffie-Hellman (DH) key exchange
 190          [RFC2631] [IEEE1363] with the client, signed using the KDC's
 191          signature key; or
 192
 193       b. a symmetric encryption key, signed using the KDC's signature
 194          key and encrypted using the client's public key.
 195
 196       Any keying material required by the client to obtain the
 197       encryption key for decrypting the KDC reply is returned in a pre-
 198       authentication field accompanying the usual reply.
 199
 200    4. The client validates the KDC's signature, obtains the encryption
 201       key, decrypts the reply, and then proceeds as usual.
 202
 203    Section 3.1 of this document enumerates the required algorithms and
 204    necessary extension message types.  Section 3.2 describes the
 205    extension messages in greater detail.
 206
 207 3.1  Definitions, Requirements, and Constants
 208
 209 3.1.1  Required Algorithms
 210
 211    All PKINIT implementations MUST support the following algorithms:
 212
 213    o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
 214       sha1-96 [RFC3962].
 215
 216
 217
 218
 219
 220 Tung & Zhu              Expires January 20, 2006                [Page 4]
 221 \f
 222 Internet-Draft                   PKINIT                        July 2005
 223
 224
 225    o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
 226
 227    o  AS reply key delivery method: Diffie-Hellman key exchange
 228       [RFC2631].
 229
 230
 231 3.1.2  Defined Message and Encryption Types
 232
 233    PKINIT makes use of the following new pre-authentication types:
 234
 235        PA_PK_AS_REQ                                 16
 236        PA_PK_AS_REP                                 17
 237
 238    PKINIT also makes use of the following new authorization data type:
 239
 240        AD_INITIAL_VERIFIED_CAS                       9
 241
 242    PKINIT introduces the following new error codes:
 243
 244        KDC_ERR_CLIENT_NOT_TRUSTED                   62
 245        KDC_ERR_INVALID_SIG                          64
 246        KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
 247        KDC_ERR_CANT_VERIFY_CERTIFICATE              70
 248        KDC_ERR_INVALID_CERTIFICATE                  71
 249        KDC_ERR_REVOKED_CERTIFICATE                  72
 250        KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
 251        KDC_ERR_CLIENT_NAME_MISMATCH                 75
 252        KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
 253
 254    PKINIT uses the following typed data types for errors:
 255
 256        TD_TRUSTED_CERTIFIERS                       104
 257        TD_INVALID_CERTIFICATES                     105
 258        TD_DH_PARAMETERS                            109
 259
 260    PKINIT defines the following encryption types, for use in the AS-REQ
 261    message to indicate acceptance of the corresponding algorithms that
 262    can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
 263    the reply:
 264
 265        dsaWithSHA1-CmsOID                            9
 266        md5WithRSAEncryption-CmsOID                  10
 267        sha1WithRSAEncryption-CmsOID                 11
 268        rc2CBC-EnvOID                                12
 269        rsaEncryption-EnvOID   (PKCS1 v1.5)          13
 270        rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
 271        des-ede3-cbc-EnvOID                          15
 272
 273
 274
 275
 276 Tung & Zhu              Expires January 20, 2006                [Page 5]
 277 \f
 278 Internet-Draft                   PKINIT                        July 2005
 279
 280
 281    The ASN.1 module for all structures defined in this document (plus
 282    IMPORT statements for all imported structures) is given in
 283    Appendix A.
 284
 285    All structures defined in or imported into this document MUST be
 286    encoded using Distinguished Encoding Rules (DER) [X690] (unless
 287    otherwise noted).  All data structures carried in OCTET STRINGs must
 288    be encoded according to the rules specified in corresponding
 289    specifications.
 290
 291    Interoperability note: Some implementations may not be able to decode
 292    wrapped CMS objects encoded with BER but not DER; specifically, they
 293    may not be able to decode infinite length encodings.  To maximize
 294    interoperability, implementers SHOULD encode CMS objects used in
 295    PKINIT with DER.
 296
 297 3.1.3  Algorithm Identifiers
 298
 299    PKINIT does not define, but does make use of, the following algorithm
 300    identifiers.
 301
 302    PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
 303    key agreement [RFC3279]:
 304
 305        dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
 306
 307    PKINIT uses the following signature algorithm identifiers [RFC3279]:
 308
 309        sha-1WithRSAEncryption (RSA with SHA1)
 310        md5WithRSAEncryption   (RSA with MD5)
 311        id-dsa-with-sha1       (DSA with SHA1)
 312
 313    PKINIT uses the following encryption algorithm identifiers [RFC3447]
 314    for encrypting the temporary key with a public key:
 315
 316        rsaEncryption          (PKCS1 v1.5)
 317        id-RSAES-OAEP          (PKCS1 v2.0)
 318
 319    PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
 320    for encrypting the AS reply key with the temporary key:
 321
 322        des-ede3-cbc           (three-key 3DES, CBC mode)
 323        rc2-cbc                (RC2, CBC mode)
 324        id-aes256-CBC          (AES-256, CBC mode)
 325
 326
 327
 328
 329
 330
 331
 332 Tung & Zhu              Expires January 20, 2006                [Page 6]
 333 \f
 334 Internet-Draft                   PKINIT                        July 2005
 335
 336
 337 3.2  PKINIT Pre-authentication Syntax and Use
 338
 339    This section defines the syntax and use of the various pre-
 340    authentication fields employed by PKINIT.
 341
 342 3.2.1  Generation of Client Request
 343
 344    The initial authentication request (AS-REQ) is sent as per [RFC4120];
 345    in addition, a pre-authentication data element, whose padata-type is
 346    PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
 347    type PA-PK-AS-REQ, is included.
 348
 349        PA-PK-AS-REQ ::= SEQUENCE {
 350           signedAuthPack          [0] IMPLICIT OCTET STRING,
 351                    -- Contains a CMS type ContentInfo encoded
 352                    -- according to [RFC3852].
 353                    -- The contentType field of the type ContentInfo
 354                    -- is id-signedData (1.2.840.113549.1.7.2),
 355                    -- and the content field is a SignedData.
 356                    -- The eContentType field for the type SignedData is
 357                    -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
 358                    -- eContent field contains the DER encoding of the
 359                    -- type AuthPack.
 360                    -- AuthPack is defined below.
 361           trustedCertifiers       [1] SEQUENCE OF
 362                       ExternalPrincipalIdentifier OPTIONAL,
 363                    -- A list of CAs, trusted by the client, that can
 364                    -- be used to certify the KDC.
 365                    -- Each ExternalPrincipalIdentifier identifies a CA
 366                    -- or a CA certificate (thereby its public key).
 367                    -- The information contained in the
 368                    -- trustedCertifiers SHOULD be used by the KDC as
 369                    -- hints to guide its selection of an appropriate
 370                    -- certificate chain to return to the client.
 371           kdcPkId                 [2] IMPLICIT OCTET STRING
 372                                       OPTIONAL,
 373                    -- Contains a CMS type SignerIdentifier encoded
 374                    -- according to [RFC3852].
 375                    -- Identifies, if present, a particular KDC
 376                    -- public key that the client already has.
 377           ...
 378        }
 379
 380        DHNonce ::= OCTET STRING
 381
 382        ExternalPrincipalIdentifier ::= SEQUENCE {
 383           subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
 384                    -- Contains a PKIX type Name encoded according to
 385
 386
 387
 388 Tung & Zhu              Expires January 20, 2006                [Page 7]
 389 \f
 390 Internet-Draft                   PKINIT                        July 2005
 391
 392
 393                    -- [RFC3280].
 394                    -- Identifies the certificate subject by the
 395                    -- distinguished subject name.
 396                    -- REQUIRED when there is a distinguished subject
 397                    -- name present in the certificate.
 398          issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
 399                    -- Contains a CMS type IssuerAndSerialNumber encoded
 400                    -- according to [RFC3852].
 401                    -- Identifies a certificate of the subject.
 402                    -- REQUIRED for TD-INVALID-CERTIFICATES and
 403                    -- TD-TRUSTED-CERTIFIERS.
 404          subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
 405                    -- Identifies the subject's public key by a key
 406                    -- identifier.  When an X.509 certificate is
 407                    -- referenced, this key identifier matches the X.509
 408                    -- subjectKeyIdentifier extension value.  When other
 409                    -- certificate formats are referenced, the documents
 410                    -- that specify the certificate format and their use
 411                    -- with the CMS must include details on matching the
 412                    -- key identifier to the appropriate certificate
 413                    -- field.
 414                    -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
 415           ...
 416        }
 417
 418        AuthPack ::= SEQUENCE {
 419           pkAuthenticator         [0] PKAuthenticator,
 420           clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
 421                    -- Type SubjectPublicKeyInfo is defined in
 422                    -- [RFC3280].
 423                    -- Specifies Diffie-Hellman domain parameters
 424                    -- and the client's public key value [IEEE1363].
 425                    -- The DH public key value is encoded as a BIT
 426                    -- STRING, as specified in Section 2.3.3 of
 427                    -- [RFC3279].
 428                    -- This field is present only if the client wishes
 429                    -- to use the Diffie-Hellman key agreement method.
 430           supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
 431                                       OPTIONAL,
 432                    -- Type AlgorithmIdentifier is defined in
 433                    -- [RFC3280].
 434                    -- List of CMS encryption types supported by the
 435                    -- client in order of (decreasing) preference.
 436           clientDHNonce           [3] DHNonce OPTIONAL,
 437                    -- Present only if the client indicates that it
 438                    -- wishes to reuse DH keys or to allow the KDC to
 439                    -- do so (see Section 3.2.3.1).
 440           ...
 441
 442
 443
 444 Tung & Zhu              Expires January 20, 2006                [Page 8]
 445 \f
 446 Internet-Draft                   PKINIT                        July 2005
 447
 448
 449        }
 450
 451        PKAuthenticator ::= SEQUENCE {
 452           cusec                   [0] INTEGER (0..999999),
 453           ctime                   [1] KerberosTime,
 454                    -- cusec and ctime are used as in [RFC4120], for
 455                    -- replay prevention.
 456           nonce                   [2] INTEGER (0..4294967295),
 457                    -- Chosen randomly;  This nonce does not need to
 458                    -- match with the nonce in the KDC-REQ-BODY.
 459           paChecksum              [3] OCTET STRING,
 460                    -- Contains the SHA1 checksum, performed over
 461                    -- KDC-REQ-BODY.
 462           ...
 463        }
 464
 465    The ContentInfo [RFC3852] structure for the signedAuthPack field is
 466    filled out as follows:
 467
 468    1.  The contentType field of the type ContentInfo is id-signedData
 469        (as defined in [RFC3852]), and the content field is a SignedData
 470        (as defined in [RFC3852]).
 471
 472    2.  The eContentType field for the type SignedData is id-pkauthdata:
 473        { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
 474        pkinit(3) pkauthdata(1) }.
 475
 476    3.  The eContent field for the type SignedData contains the DER
 477        encoding of the type AuthPack.
 478
 479    4.  The signerInfos field of the type SignedData contains a single
 480        signerInfo, which contains the signature over the type AuthPack.
 481
 482    5.  The certificates field of the type SignedData contains
 483        certificates intended to facilitate certification path
 484        construction, so that the KDC can verify the signature over the
 485        type AuthPack.  For path validation, these certificates SHOULD be
 486        sufficient to construct at least one certification path from the
 487        client certificate to one trust anchor acceptable by the KDC
 488        [CAPATH].  The client MUST be capable of including such a set of
 489        certificates if configured to do so.  The certificates field MUST
 490        NOT contain "root" CA certificates.
 491
 492    6.  The client's Diffie-Hellman public value (clientPublicValue) is
 493        included if and only if the client wishes to use the Diffie-
 494        Hellman key agreement method.  The Diffie-Hellman domain
 495        parameters [IEEE1363] for the client's public key are specified
 496        in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
 497
 498
 499
 500 Tung & Zhu              Expires January 20, 2006                [Page 9]
 501 \f
 502 Internet-Draft                   PKINIT                        July 2005
 503
 504
 505        and the client's Diffie-Hellman public key value is mapped to a
 506        subjectPublicKey (a BIT STRING) according to [RFC3279].  When
 507        using the Diffie-Hellman key agreement method, implementations
 508        MUST support Oakley 1024-bit Modular Exponential (MODP) well-
 509        known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
 510        14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
 511        group 16 [RFC3526].
 512
 513        The Diffie-Hellman field size should be chosen so as to provide
 514        sufficient cryptographic security [RFC3766].
 515
 516        When MODP Diffie-Hellman is used, the exponents should have at
 517        least twice as many bits as the symmetric keys that will be
 518        derived from them [ODL99].
 519
 520    7.  The client may wish to reuse DH keys or to allow the KDC to do so
 521        (see Section 3.2.3.1).  If so, then the client includes the
 522        clientDHNonce field.  This nonce string needs to be as long as
 523        the longest key length of the symmetric key types that the client
 524        supports.  This nonce MUST be chosen randomly.
 525
 526
 527 3.2.2  Receipt of Client Request
 528
 529    Upon receiving the client's request, the KDC validates it.  This
 530    section describes the steps that the KDC MUST (unless otherwise
 531    noted) take in validating the request.
 532
 533    The KDC verifies the client's signature in the signedAuthPack field
 534    according to [RFC3852].
 535
 536    If, while validating the client's X.509 certificate [RFC3280], the
 537    KDC cannot build a certification path to validate the client's
 538    certificate, it sends back a KRB-ERROR [RFC4120] message with the
 539    code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
 540    this error message is a TYPED-DATA (as defined in [RFC4120]) that
 541    contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
 542    whose data-value contains the DER encoding of the type TD-TRUSTED-
 543    CERTIFIERS:
 544
 545        TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
 546                       ExternalPrincipalIdentifier
 547                    -- Identifies a list of CAs trusted by the KDC.
 548                    -- Each ExternalPrincipalIdentifier identifies a CA
 549                    -- or a CA certificate (thereby its public key).
 550
 551    Upon receiving this error message, the client SHOULD retry only if it
 552    has a different set of certificates (from those of the previous
 553
 554
 555
 556 Tung & Zhu              Expires January 20, 2006               [Page 10]
 557 \f
 558 Internet-Draft                   PKINIT                        July 2005
 559
 560
 561    requests) that form a certification path (or a partial path) from one
 562    of the trust anchors acceptable by the KDC to its own certificate.
 563
 564    If, while processing the certification path, the KDC determines that
 565    the signature on one of the certificates in the signedAuthPack field
 566    is invalid, it returns a KRB-ERROR [RFC4120] message with the code
 567    KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
 568    message is a TYPED-DATA that contains an element whose data-type is
 569    TD_INVALID_CERTIFICATES, and whose data-value contains the DER
 570    encoding of the type TD-INVALID-CERTIFICATES:
 571
 572        TD-INVALID-CERTIFICATES ::= SEQUENCE OF
 573                       ExternalPrincipalIdentifier
 574                    -- Each ExternalPrincipalIdentifier identifies a
 575                    -- certificate (sent by the client) with an invalid
 576                    -- signature.
 577
 578    If more than one X.509 certificate signature is invalid, the KDC MAY
 579    include one IssuerAndSerialNumber per invalid signature within the
 580    TD-INVALID-CERTIFICATES.
 581
 582    The client's X.509 certificate is validated according to [RFC3280].
 583
 584    Based on local policy, the KDC may also check whether any X.509
 585    certificates in the certification path validating the client's
 586    certificate have been revoked.  If any of them have been revoked, the
 587    KDC MUST return an error message with the code
 588    KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
 589    revocation status but is unable to do so, it SHOULD return an error
 590    message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
 591    certificate or certificates affected are identified exactly as for
 592    the error code KDC_ERR_INVALID_CERTIFICATE (see above).
 593
 594    Note that the TD_INVALID_CERTIFICATES error data is only used to
 595    identify invalid certificates sent by the client in the request.
 596
 597    The client's public key is then used to verify the signature.  If the
 598    signature fails to verify, the KDC MUST return an error message with
 599    the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
 600    this error message.
 601
 602    In addition to validating the client's signature, the KDC MUST also
 603    check that the client's public key used to verify the client's
 604    signature is bound to the client's principal name as specified in the
 605    AS-REQ as follows:
 606
 607
 608
 609
 610
 611
 612 Tung & Zhu              Expires January 20, 2006               [Page 11]
 613 \f
 614 Internet-Draft                   PKINIT                        July 2005
 615
 616
 617    1. If the KDC has its own binding between either the client's
 618       signature-verification public key or the client's certificate and
 619       the client's Kerberos principal name, it uses that binding.
 620
 621    2. Otherwise, if the client's X.509 certificate contains a Subject
 622       Alternative Name (SAN) extension carrying a KRB5PrincipalName
 623       (defined below) in the otherName field of the type GeneralName
 624       [RFC3280], it binds the client's X.509 certificate to that name.
 625
 626       The type of the otherName field is AnotherName.  The type-id field
 627       of the type AnotherName is id-pksan:
 628
 629        id-pksan OBJECT IDENTIFIER ::=
 630          { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
 631            x509-sanan (2) }
 632
 633       And the value field of the type AnotherName is a
 634       KRB5PrincipalName.
 635
 636        KRB5PrincipalName ::= SEQUENCE {
 637            realm                   [0] Realm,
 638            principalName           [1] PrincipalName
 639        }
 640
 641    If the KDC does not have its own binding and there is no
 642    KRB5PrincipalName name present in the client's X.509 certificate, or
 643    if the Kerberos name in the request does not match the
 644    KRB5PrincipalName in the client's X.509 certificate (including the
 645    realm name), the KDC MUST return an error message with the code
 646    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
 647    this error message.
 648
 649    Even if the certification path is validated and the certificate is
 650    mapped to the client's principal name, the KDC may decide not to
 651    accept the client's certificate, depending on local policy.
 652
 653    The KDC MAY require the presence of an Extended Key Usage (EKU)
 654    KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
 655    client's X.509 certificate:
 656
 657        id-pkekuoid OBJECT IDENTIFIER ::=
 658          { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
 659            pkinit(3) pkekuoid(4) }
 660               -- PKINIT client authentication.
 661               -- Key usage bits that MUST be consistent:
 662               -- digitalSignature.
 663
 664    If this EKU KeyPurposeId is required but it is not present or if the
 665
 666
 667
 668 Tung & Zhu              Expires January 20, 2006               [Page 12]
 669 \f
 670 Internet-Draft                   PKINIT                        July 2005
 671
 672
 673    client certificate is restricted not to be used for PKINIT client
 674    authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
 675    an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
 676    is no accompanying e-data for this error message.  KDCs implementing
 677    this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
 678    logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
 679    are a large number of X.509 client certificates deployed for use with
 680    PKINIT which have this EKU.
 681
 682    As a matter of local policy, the KDC MAY decide to reject requests on
 683    the basis of the absence or presence of other specific EKU OID's.
 684
 685    If the client's public key is not accepted, the KDC returns an error
 686    message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
 687
 688    The KDC MUST check the timestamp to ensure that the request is not a
 689    replay, and that the time skew falls within acceptable limits.  The
 690    recommendations for clock skew times in [RFC4120] apply here.  If the
 691    check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
 692    KRB_AP_ERR_SKEW, respectively.
 693
 694    If the clientPublicValue is filled in, indicating that the client
 695    wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
 696    check to see if the key parameters satisfy its policy.  If they do
 697    not, it MUST return an error message with the code
 698    KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
 699    TYPED-DATA that contains an element whose data-type is
 700    TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
 701    the type TD-DH-PARAMETERS:
 702
 703        TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
 704                    -- Each AlgorithmIdentifier specifies a set of
 705                    -- Diffie-Hellman domain parameters [IEEE1363].
 706                    -- This list is in decreasing preference order.
 707
 708    TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
 709    that the KDC supports in decreasing preference order, from which the
 710    client SHOULD pick one to retry the request.
 711
 712    If the client included a kdcPkId field in the PA-PK-AS-REQ and the
 713    KDC does not possess the corresponding key, the KDC MUST ignore the
 714    kdcPkId field as if the client did not include one.
 715
 716    If there is a supportedCMSTypes field in the AuthPack, the KDC must
 717    check to see if it supports any of the listed types.  If it supports
 718    more than one of the types, the KDC SHOULD use the one listed first.
 719    If it does not support any of them, it MUST return an error message
 720    with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
 721
 722
 723
 724 Tung & Zhu              Expires January 20, 2006               [Page 13]
 725 \f
 726 Internet-Draft                   PKINIT                        July 2005
 727
 728
 729 3.2.3  Generation of KDC Reply
 730
 731    Assuming that the client's request has been properly validated, the
 732    KDC proceeds as per [RFC4120], except as follows.
 733
 734    The KDC MUST set the initial flag and include an authorization data
 735    element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
 736    ticket.  The ad-data [RFC4120] field contains the DER encoding of the
 737    type AD-INITIAL-VERIFIED-CAS:
 738
 739        AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
 740                       ExternalPrincipalIdentifier
 741                    -- Identifies the certification path based on which
 742                    -- the client certificate was validated.
 743                    -- Each ExternalPrincipalIdentifier identifies a CA
 744                    -- or a CA certificate (thereby its public key).
 745
 746    The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
 747    containers if the list of CAs satisfies the AS' realm's local policy
 748    (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
 749    [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
 750    from tickets used within a PA-TGS-REQ of the TGS-REQ into the
 751    resulting ticket.  If the list of CAs satisfies the local KDC's
 752    realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
 753    container, otherwise it MAY unwrap the authorization data out of the
 754    AD-IF-RELEVANT container.
 755
 756    Application servers that understand this authorization data type
 757    SHOULD apply local policy to determine whether a given ticket bearing
 758    such a type *not* contained within an AD-IF-RELEVANT container is
 759    acceptable.  (This corresponds to the AP server checking the
 760    transited field when the TRANSITED-POLICY-CHECKED flag has not been
 761    set [RFC4120].)  If such a data type is contained within an AD-IF-
 762    RELEVANT container, AP servers MAY apply local policy to determine
 763    whether the authorization data is acceptable.
 764
 765    The content of the AS-REP is otherwise unchanged from [RFC4120].  The
 766    KDC encrypts the reply as usual, but not with the client's long-term
 767    key.  Instead, it encrypts it with either a shared key derived from a
 768    Diffie-Hellman exchange, or a generated encryption key.  The contents
 769    of the PA-PK-AS-REP indicate which key delivery method is used:
 770
 771        PA-PK-AS-REP ::= CHOICE {
 772           dhInfo                  [0] DHRepInfo,
 773                    -- Selected when Diffie-Hellman key exchange is
 774                    -- used.
 775           encKeyPack              [1] IMPLICIT OCTET STRING,
 776                    -- Selected when public key encryption is used.
 777
 778
 779
 780 Tung & Zhu              Expires January 20, 2006               [Page 14]
 781 \f
 782 Internet-Draft                   PKINIT                        July 2005
 783
 784
 785                    -- Contains a CMS type ContentInfo encoded
 786                    -- according to [RFC3852].
 787                    -- The contentType field of the type ContentInfo is
 788                    -- id-envelopedData (1.2.840.113549.1.7.3).
 789                    -- The content field is an EnvelopedData.
 790                    -- The contentType field for the type EnvelopedData
 791                    -- is id-signedData (1.2.840.113549.1.7.2).
 792                    -- The eContentType field for the inner type
 793                    -- SignedData (when unencrypted) is id-pkrkeydata
 794                    -- (1.2.840.113549.1.7.3) and the eContent field
 795                    -- contains the DER encoding of the type
 796                    -- ReplyKeyPack.
 797                    -- ReplyKeyPack is defined in Section 3.2.3.2.
 798           ...
 799        }
 800
 801        DHRepInfo ::= SEQUENCE {
 802           dhSignedData            [0] IMPLICIT OCTET STRING,
 803                    -- Contains a CMS type ContentInfo encoded according
 804                    -- to [RFC3852].
 805                    -- The contentType field of the type ContentInfo is
 806                    -- id-signedData (1.2.840.113549.1.7.2), and the
 807                    -- content field is a SignedData.
 808                    -- The eContentType field for the type SignedData is
 809                    -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
 810                    -- eContent field contains the DER encoding of the
 811                    -- type KDCDHKeyInfo.
 812                    -- KDCDHKeyInfo is defined below.
 813           serverDHNonce           [1] DHNonce OPTIONAL
 814                    -- Present if and only if dhKeyExpiration is
 815                    -- present in the KDCDHKeyInfo.
 816        }
 817
 818        KDCDHKeyInfo ::= SEQUENCE {
 819           subjectPublicKey        [0] BIT STRING,
 820                    -- KDC's DH public key.
 821                    -- The DH public key value is encoded as a BIT
 822                    -- STRING, as specified in Section 2.3.3 of
 823                    -- [RFC3279].
 824           nonce                   [1] INTEGER (0..4294967295),
 825                    -- Contains the nonce in the PKAuthenticator of the
 826                    -- request if DH keys are NOT reused,
 827                    -- 0 otherwise.
 828           dhKeyExpiration         [2] KerberosTime OPTIONAL,
 829                    -- Expiration time for KDC's key pair,
 830                    -- present if and only if DH keys are reused. If
 831                    -- this field is omitted then the serverDHNonce
 832                    -- field MUST also be omitted. See Section 3.2.3.1.
 833
 834
 835
 836 Tung & Zhu              Expires January 20, 2006               [Page 15]
 837 \f
 838 Internet-Draft                   PKINIT                        July 2005
 839
 840
 841           ...
 842        }
 843
 844
 845 3.2.3.1  Using Diffie-Hellman Key Exchange
 846
 847    In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
 848
 849    The ContentInfo [RFC3852] structure for the dhSignedData field is
 850    filled in as follows:
 851
 852    1.  The contentType field of the type ContentInfo is id-signedData
 853        (as defined in [RFC3852]), and the content field is a SignedData
 854        (as defined in [RFC3852]).
 855
 856    2.  The eContentType field for the type SignedData is the OID value
 857        for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
 858        security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
 859
 860    3.  The eContent field for the type SignedData contains the DER
 861        encoding of the type KDCDHKeyInfo.
 862
 863    4.  The signerInfos field of the type SignedData contains a single
 864        signerInfo, which contains the signature over the type
 865        KDCDHKeyInfo.
 866
 867    5.  The certificates field of the type SignedData contains
 868        certificates intended to facilitate certification path
 869        construction, so that the client can verify the KDC's signature
 870        over the type KDCDHKeyInfo.  The information contained in the
 871        trustedCertifiers in the request SHOULD be used by the KDC as
 872        hints to guide its selection of an appropriate certificate chain
 873        to return to the client.  This field may only. be left empty if
 874        the KDC public key specified by the kdcPkId field in the PA-PK-
 875        AS-REQ was used for signing.  Otherwise, for path validation,
 876        these certificates SHOULD be sufficient to construct at least one
 877        certification path from the KDC certificate to one trust anchor
 878        acceptable by the client [CAPATH].  The KDC MUST be capable of
 879        including such a set of certificates if configured to do so.  The
 880        certificates field MUST NOT contain "root" CA certificates.
 881
 882    6.  If the client included the clientDHNonce field, then the KDC may
 883        choose to reuse its DH keys (see Section 3.2.3.1).  If the server
 884        reuses DH keys then it MUST include an expiration time in the
 885        dhKeyExpiration field.  Past the point of the expiration time,
 886        the signature over the type DHRepInfo is considered expired/
 887        invalid.  When the server reuses DH keys then it MUST include a
 888        serverDHNonce at least as long as the length of keys for the
 889
 890
 891
 892 Tung & Zhu              Expires January 20, 2006               [Page 16]
 893 \f
 894 Internet-Draft                   PKINIT                        July 2005
 895
 896
 897        symmetric encryption system used to encrypt the AS reply.  Note
 898        that including the serverDHNonce changes how the client and
 899        server calculate the key to use to encrypt the reply; see below
 900        for details.  The KDC SHOULD NOT reuse DH keys unless the
 901        clientDHNonce field is present in the request.
 902
 903    The AS reply key is derived as follows:
 904
 905    1. Both the KDC and the client calculate the shared secret value as
 906       follows:
 907
 908       a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
 909          shared secret value.  DHSharedSecret is the value ZZ as
 910          described in Section 2.1.1 of [RFC2631].
 911
 912       DHSharedSecret is first padded with leading zeros such that the
 913       size of DHSharedSecret in octets is the same as that of the
 914       modulus, then represented as a string of octets in big-endian
 915       order.
 916
 917       Implementation note: Both the client and the KDC can cache the
 918       triple (ya, yb, DHSharedSecret), where ya is the client's public
 919       key and yb is the KDC's public key.  If both ya and yb are the
 920       same in a later exchange, the cached DHSharedSecret can be used.
 921
 922    2. Let K be the key-generation seed length [RFC3961] of the AS reply
 923       key whose enctype is selected according to [RFC4120].
 924
 925    3. Define the function octetstring2key() as follows:
 926
 927            octetstring2key(x) == random-to-key(K-truncate(
 928                                     SHA1(0x00 | x) |
 929                                     SHA1(0x01 | x) |
 930                                     SHA1(0x02 | x) |
 931                                     ...
 932                                     ))
 933
 934       where x is an octet string; | is the concatenation operator; 0x00,
 935       0x01, 0x02, etc., are each represented as a single octet; random-
 936       to-key() is an operation that generates a protocol key from a
 937       bitstring of length K; and K-truncate truncates its input to the
 938       first K bits.  Both K and random-to-key() are as defined in the
 939       kcrypto profile [RFC3961] for the enctype of the AS reply key.
 940
 941
 942
 943
 944
 945
 946
 947
 948 Tung & Zhu              Expires January 20, 2006               [Page 17]
 949 \f
 950 Internet-Draft                   PKINIT                        July 2005
 951
 952
 953    4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
 954       the serverDHNonce; otherwise, let both n_c and n_k be empty octet
 955       strings.
 956
 957    5. The AS reply key k is:
 958
 959            k = octetstring2key(DHSharedSecret | n_c | n_k)
 960
 961
 962 3.2.3.2  Using Public Key Encryption
 963
 964    In this case, the PA-PK-AS-REP contains a ContentInfo structure
 965    wrapped in an OCTET STRING.  The AS reply key is encrypted in the
 966    encKeyPack field, which contains data of type ReplyKeyPack:
 967
 968        ReplyKeyPack ::= SEQUENCE {
 969           replyKey                [0] EncryptionKey,
 970                    -- Contains the session key used to encrypt the
 971                    -- enc-part field in the AS-REP.
 972           asChecksum              [1] Checksum,
 973                   -- Contains the checksum of the AS-REQ
 974                   -- corresponding to the containing AS-REP.
 975                   -- The checksum is performed over the type AS-REQ.
 976                   -- The protocol key [RFC3961] of the checksum is the
 977                   -- replyKey and the key usage number is 6.
 978                   -- If the replyKey's enctype is "newer" [RFC4120]
 979                   -- [RFC4121], the checksum is the required
 980                   -- checksum operation [RFC3961] for that enctype.
 981                   -- The client MUST verify this checksum upon receipt
 982                   -- of the AS-REP.
 983           ...
 984        }
 985
 986    The ContentInfo [RFC3852] structure for the encKeyPack field is
 987    filled in as follows:
 988
 989    1.  The contentType field of the type ContentInfo is id-envelopedData
 990        (as defined in [RFC3852]), and the content field is an
 991        EnvelopedData (as defined in [RFC3852]).
 992
 993    2.  The contentType field for the type EnvelopedData is id-
 994        signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
 995        pkcs (1) pkcs7 (7) signedData (2) }.
 996
 997    3.  The eContentType field for the inner type SignedData (when
 998        decrypted from the encryptedContent field for the type
 999        EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
1000        internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
1001
1002
1003
1004 Tung & Zhu              Expires January 20, 2006               [Page 18]
1005 \f
1006 Internet-Draft                   PKINIT                        July 2005
1007
1008
1009    4.  The eContent field for the inner type SignedData contains the DER
1010        encoding of the type ReplyKeyPack.
1011
1012    5.  The signerInfos field of the inner type SignedData contains a
1013        single signerInfo, which contains the signature over the type
1014        ReplyKeyPack.
1015
1016    6.  The certificates field of the inner type SignedData contains
1017        certificates intended to facilitate certification path
1018        construction, so that the client can verify the KDC's signature
1019        over the type ReplyKeyPack.  The information contained in the
1020        trustedCertifiers in the request SHOULD be used by the KDC as
1021        hints to guide its selection of an appropriate certificate chain
1022        to return to the client.  This field may only be left empty if
1023        the KDC public key specified by the kdcPkId field in the PA-PK-
1024        AS-REQ was used for signing.  Otherwise, for path validation,
1025        these certificates SHOULD be sufficient to construct at least one
1026        certification path from the KDC certificate to one trust anchor
1027        acceptable by the client [CAPATH].  The KDC MUST be capable of
1028        including such a set of certificates if configured to do so.  The
1029        certificates field MUST NOT contain "root" CA certificates.
1030
1031    7.  The recipientInfos field of the type EnvelopedData is a SET which
1032        MUST contain exactly one member of type KeyTransRecipientInfo.
1033        The encryptedKey of this member contains the temporary key which
1034        is encrypted using the client's public key.
1035
1036    8.  The unprotectedAttrs or originatorInfo fields of the type
1037        EnvelopedData MAY be present.
1038
1039    Implementations of this RSA encryption key delivery method are
1040    RECOMMENDED to support for RSA keys at least 2048 bits in size.
1041
1042 3.2.4  Receipt of KDC Reply
1043
1044    Upon receipt of the KDC's reply, the client proceeds as follows.  If
1045    the PA-PK-AS-REP contains the dhSignedData field, the client derives
1046    the AS reply key using the same procedure used by the KDC as defined
1047    in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
1048    field, and the client decrypts and extracts the temporary key in the
1049    encryptedKey field of the member KeyTransRecipientInfo, and then uses
1050    that as the AS reply key.
1051
1052    In either case, the client MUST verify the signature in the
1053    SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
1054    be validated according to [RFC3280].  In addition, unless the client
1055    can otherwise verify that the public key used to verify the KDC's
1056    signature is bound to the KDC of the target realm, the KDC's X.509
1057
1058
1059
1060 Tung & Zhu              Expires January 20, 2006               [Page 19]
1061 \f
1062 Internet-Draft                   PKINIT                        July 2005
1063
1064
1065    certificate MUST contain a Subject Alternative Name extension
1066    [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
1067    defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
1068    matches the name of the TGS of the target realm (as defined in
1069    Section 7.3 of [RFC4120]).
1070
1071    Based on local policy, the client MAY require that the KDC
1072    certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
1073
1074        id-pkkdcekuoid OBJECT IDENTIFIER ::=
1075          { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1076            pkinit(3) pkkdcekuoid(5) }
1077               -- Signing KDC responses.
1078               -- Key usage bits that MUST be consistent:
1079               -- digitalSignature.
1080
1081    If all applicable checks are satisfied, the client then decrypts the
1082    enc-part field of the KDC-REP in the AS-REP using the AS reply key,
1083    and then proceeds as described in [RFC4120].
1084
1085    Implementation note: CAs issuing KDC certificates SHOULD place all
1086    "short" and "fully-qualified" Kerberos realm names of the KDC (one
1087    per GeneralName [RFC3280]) into the KDC certificate to allow maximum
1088    flexibility.
1089
1090 3.3  Interoperability Requirements
1091
1092    The client MUST be capable of sending a set of certificates
1093    sufficient to allow the KDC to construct a certification path for the
1094    client's certificate, if the correct set of certificates is provided
1095    through configuration or policy.
1096
1097    If the client sends all the X.509 certificates on a certification
1098    path to a trust anchor acceptable by the KDC, and the KDC can not
1099    verify the client's public key otherwise, the KDC MUST be able to
1100    process path validation for the client's certificate based on the
1101    certificates in the request.
1102
1103    The KDC MUST be capable of sending a set of certificates sufficient
1104    to allow the client to construct a certification path for the KDC's
1105    certificate, if the correct set of certificates is provided through
1106    configuration or policy.
1107
1108    If the KDC sends all the X.509 certificates on a certification path
1109    to a trust anchor acceptable by the client, and the client can not
1110    verify the KDC's public key otherwise, the client MUST be able to
1111    process path validation for the KDC's certificate based on the
1112    certificates in the reply.
1113
1114
1115
1116 Tung & Zhu              Expires January 20, 2006               [Page 20]
1117 \f
1118 Internet-Draft                   PKINIT                        July 2005
1119
1120
1121 3.4  KDC Indication of PKINIT Support
1122
1123    If pre-authentication is required, but was not present in the
1124    request, per [RFC4120] an error message with the code
1125    KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
1126    stored in the e-data field of the KRB-ERROR message to specify which
1127    pre-authentication mechanisms are acceptable.  The KDC can then
1128    indicate the support of PKINIT by including an empty element whose
1129    padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
1130
1131    Otherwise if it is required by the KDC's local policy that the client
1132    must be pre-authenticated using the pre-authentication mechanism
1133    specified in this document, but no PKINIT pre-authentication was
1134    present in the request, an error message with the code
1135    KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1136
1137    KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
1138    the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1139    STRING), and clients MUST ignore this and any other value.  Future
1140    extensions to this protocol may specify other data to send instead of
1141    an empty OCTET STRING.
1142
1143 4.  Security Considerations
1144
1145    The symmetric reply key size and Diffie-Hellman field size or RSA
1146    modulus size should be chosen so as to provide sufficient
1147    cryptographic security [RFC3766].
1148
1149    When MODP Diffie-Hellman is used, the exponents should have at least
1150    twice as many bits as the symmetric keys that will be derived from
1151    them [ODL99].
1152
1153    PKINIT raises certain security considerations beyond those that can
1154    be regulated strictly in protocol definitions.  We will address them
1155    in this section.
1156
1157    PKINIT extends the cross-realm model to the public-key
1158    infrastructure.  Users of PKINIT must understand security policies
1159    and procedures appropriate to the use of Public Key Infrastructures
1160    [RFC3280].
1161
1162    Standard Kerberos allows the possibility of interactions between
1163    cryptosystems of varying strengths; this document adds interactions
1164    with public-key cryptosystems to Kerberos.  Some administrative
1165    policies may allow the use of relatively weak public keys.  Using
1166    such keys to wrap data encrypted under stronger conventional
1167    cryptosystems may be inappropriate.
1168
1169
1170
1171
1172 Tung & Zhu              Expires January 20, 2006               [Page 21]
1173 \f
1174 Internet-Draft                   PKINIT                        July 2005
1175
1176
1177    PKINIT requires keys for symmetric cryptosystems to be generated.
1178    Some such systems contain "weak" keys.  For recommendations regarding
1179    these weak keys, see [RFC4120].
1180
1181    PKINIT allows the use of the same RSA key pair for encryption and
1182    signing when doing RSA encryption based key delivery.  This is not
1183    recommended usage of RSA keys [RFC3447], by using DH based key
1184    delivery this is avoided.
1185
1186    Care should be taken in how certificates are chosen for the purposes
1187    of authentication using PKINIT.  Some local policies may require that
1188    key escrow be used for certain certificate types.  Deployers of
1189    PKINIT should be aware of the implications of using certificates that
1190    have escrowed keys for the purposes of authentication.  Because
1191    signing only certificates are normally not escrowed, by using DH
1192    based key delivery this is avoided.
1193
1194    PKINIT does not provide for a "return routability" test to prevent
1195    attackers from mounting a denial-of-service attack on the KDC by
1196    causing it to perform unnecessary and expensive public-key
1197    operations.  Strictly speaking, this is also true of standard
1198    Kerberos, although the potential cost is not as great, because
1199    standard Kerberos does not make use of public-key cryptography.  By
1200    using DH based key delivery and reusing DH keys, the necessary crypto
1201    processing cost per request can be minimized.
1202
1203    The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1204    permit empty SEQUENCEs to be encoded.  Such empty sequences may only
1205    be used if the KDC itself vouches for the user's certificate.
1206
1207 5.  Acknowledgements
1208
1209    The following people have made significant contributions to this
1210    draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
1211    Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
1212    Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
1213    Jaganathan, Chaskiel M Grundman and Stefan Santesson.
1214
1215    Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
1216    Jonathan Trostle who wrote earlier versions of this document.
1217
1218    The authors are indebted to the Kerberos working group chair Jeffrey
1219    Hutzelman who kept track of various issues and was enormously helpful
1220    during the creation of this document.
1221
1222    Some of the ideas on which this document is based arose during
1223    discussions over several years between members of the SAAG, the IETF
1224    CAT working group, and the PSRG, regarding integration of Kerberos
1225
1226
1227
1228 Tung & Zhu              Expires January 20, 2006               [Page 22]
1229 \f
1230 Internet-Draft                   PKINIT                        July 2005
1231
1232
1233    and SPX.  Some ideas have also been drawn from the DASS system.
1234    These changes are by no means endorsed by these groups.  This is an
1235    attempt to revive some of the goals of those groups, and this
1236    document approaches those goals primarily from the Kerberos
1237    perspective.
1238
1239    Lastly, comments from groups working on similar ideas in DCE have
1240    been invaluable.
1241
1242 6.  IANA Considerations
1243
1244    This document has no actions for IANA.
1245
1246 7.  References
1247
1248 7.1  Normative References
1249
1250    [IEEE1363]
1251               IEEE, "Standard Specifications for Public Key
1252               Cryptography", IEEE 1363, 2000.
1253
1254    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1255               Requirement Levels", BCP 14, RFC 2119, March 1997.
1256
1257    [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
1258               RFC 2412, November 1998.
1259
1260    [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
1261               RFC 2631, June 1999.
1262
1263    [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
1264               Identifiers for the Internet X.509 Public Key
1265               Infrastructure Certificate and Certificate Revocation List
1266               (CRL) Profile", RFC 3279, April 2002.
1267
1268    [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
1269               X.509 Public Key Infrastructure Certificate and
1270               Certificate Revocation List (CRL) Profile", RFC 3280,
1271               April 2002.
1272
1273    [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
1274               Algorithms", RFC 3370, August 2002.
1275
1276    [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1277               Standards (PKCS) #1: RSA Cryptography Specifications
1278               Version 2.1", RFC 3447, February 2003.
1279
1280    [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1281
1282
1283
1284 Tung & Zhu              Expires January 20, 2006               [Page 23]
1285 \f
1286 Internet-Draft                   PKINIT                        July 2005
1287
1288
1289               Diffie-Hellman groups for Internet Key Exchange (IKE)",
1290               RFC 3526, May 2003.
1291
1292    [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
1293               Encryption Algorithm in Cryptographic Message Syntax
1294               (CMS)", RFC 3565, July 2003.
1295
1296    [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
1297               Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1298               RFC 3766, April 2004.
1299
1300    [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
1301               RFC 3852, July 2004.
1302
1303    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
1304               Kerberos 5", RFC 3961, February 2005.
1305
1306    [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
1307               Encryption for Kerberos 5", RFC 3962, February 2005.
1308
1309    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1310               Kerberos Network Authentication Service (V5)", RFC 4120,
1311               July 2005.
1312
1313    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
1314               Version 5 Generic Security Service Application Program
1315               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
1316               July 2005.
1317
1318    [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication
1319               Framework.  1997.
1320
1321    [X690]     ASN.1 encoding rules: Specification of Basic Encoding
1322               Rules (BER), Canonical Encoding Rules (CER) and
1323               Distinguished Encoding Rules (DER), ITU-T Recommendation
1324               X.690 (1997) | ISO/IEC International Standard
1325               8825-1:1998.
1326
1327 7.2  Informative References
1328
1329    [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
1330               pkix-certpathbuild.  Work in Progress.
1331
1332    [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1333               Sizes", Journal of Cryptology 14 (2001) 255-293.
1334
1335
1336 Tung & Zhu              Expires January 20, 2006               [Page 24]
1337 \f
1338 Internet-Draft                   PKINIT                        July 2005
1339
1340
1341
1342    [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
1343               future, Designs, Codes, and Cryptography (1999)".
1344
1345
1346 Authors' Addresses
1347
1348    Brian Tung
1349    USC Information Sciences Institute
1350    4676 Admiralty Way Suite 1001, Marina del Rey CA
1351    Marina del Rey, CA  90292
1352    US
1353
1354    Email: brian@isi.edu
1355
1356
1357    Larry Zhu
1358    Microsoft Corporation
1359    One Microsoft Way
1360    Redmond, WA  98052
1361    US
1362
1363    Email: lzhu@microsoft.com
1364
1365 Appendix A.  PKINIT ASN.1 Module
1366
1367        KerberosV5-PK-INIT-SPEC {
1368                iso(1) identified-organization(3) dod(6) internet(1)
1369                security(5) kerberosV5(2) modules(4) pkinit(5)
1370        } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1371
1372        IMPORTS
1373            SubjectPublicKeyInfo, AlgorithmIdentifier
1374                FROM PKIX1Explicit88 { iso (1)
1375                  identified-organization (3) dod (6) internet (1)
1376                  security (5) mechanisms (5) pkix (7) id-mod (0)
1377                  id-pkix1-explicit (18) }
1378                  -- As defined in RFC 3280.
1379
1380            DomainParameters
1381                FROM PKIX1Algorithms88 { iso(1)
1382                  identified-organization(3) dod(6)
1383                  internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1384                  id-mod-pkix1-algorithms(17) }
1385                  -- As defined in RFC 3279.
1386
1387            KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
1388                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1389
1390
1391
1392 Tung & Zhu              Expires January 20, 2006               [Page 25]
1393 \f
1394 Internet-Draft                   PKINIT                        July 2005
1395
1396
1397                  dod(6) internet(1) security(5) kerberosV5(2)
1398                  modules(4) krb5spec2(2) } ;
1399
1400        id-pkinit OBJECT IDENTIFIER ::=
1401          { iso (1) org (3) dod (6) internet (1) security (5)
1402            kerberosv5 (2) pkinit (3) }
1403
1404        id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
1405        id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
1406        id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
1407        id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
1408        id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
1409
1410        pa-pk-as-req INTEGER ::=                  16
1411        pa-pk-as-rep INTEGER ::=                  17
1412
1413        ad-initial-verified-cas INTEGER ::=        9
1414
1415        td-trusted-certifiers INTEGER ::=        104
1416        td-invalid-certificates INTEGER ::=      105
1417        td-dh-parameters INTEGER ::=             109
1418
1419        PA-PK-AS-REQ ::= SEQUENCE {
1420           signedAuthPack          [0] IMPLICIT OCTET STRING,
1421                    -- Contains a CMS type ContentInfo encoded
1422                    -- according to [RFC3852].
1423                    -- The contentType field of the type ContentInfo
1424                    -- is id-signedData (1.2.840.113549.1.7.2),
1425                    -- and the content field is a SignedData.
1426                    -- The eContentType field for the type SignedData is
1427                    -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
1428                    -- eContent field contains the DER encoding of the
1429                    -- type AuthPack.
1430                    -- AuthPack is defined below.
1431           trustedCertifiers       [1] SEQUENCE OF
1432                       ExternalPrincipalIdentifier OPTIONAL,
1433                    -- A list of CAs, trusted by the client, that can
1434                    -- be used to certify the KDC.
1435                    -- Each ExternalPrincipalIdentifier identifies a CA
1436                    -- or a CA certificate (thereby its public key).
1437                    -- The information contained in the
1438                    -- trustedCertifiers SHOULD be used by the KDC as
1439                    -- hints to guide its selection of an appropriate
1440                    -- certificate chain to return to the client.
1441           kdcPkId                 [2] IMPLICIT OCTET STRING
1442                                       OPTIONAL,
1443                    -- Contains a CMS type SignerIdentifier encoded
1444                    -- according to [RFC3852].
1445
1446
1447
1448 Tung & Zhu              Expires January 20, 2006               [Page 26]
1449 \f
1450 Internet-Draft                   PKINIT                        July 2005
1451
1452
1453                    -- Identifies, if present, a particular KDC
1454                    -- public key that the client already has.
1455           ...
1456        }
1457
1458        DHNonce ::= OCTET STRING
1459
1460        ExternalPrincipalIdentifier ::= SEQUENCE {
1461           subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
1462                    -- Contains a PKIX type Name encoded according to
1463                    -- [RFC3280].
1464                    -- Identifies the certificate subject by the
1465                    -- distinguished subject name.
1466                    -- REQUIRED when there is a distinguished subject
1467                    -- name present in the certificate.
1468          issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
1469                    -- Contains a CMS type IssuerAndSerialNumber encoded
1470                    -- according to [RFC3852].
1471                    -- Identifies a certificate of the subject.
1472                    -- REQUIRED for TD-INVALID-CERTIFICATES and
1473                    -- TD-TRUSTED-CERTIFIERS.
1474          subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
1475                    -- Identifies the subject's public key by a key
1476                    -- identifier.  When an X.509 certificate is
1477                    -- referenced, this key identifier matches the X.509
1478                    -- subjectKeyIdentifier extension value.  When other
1479                    -- certificate formats are referenced, the documents
1480                    -- that specify the certificate format and their use
1481                    -- with the CMS must include details on matching the
1482                    -- key identifier to the appropriate certificate
1483                    -- field.
1484                    -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
1485           ...
1486        }
1487
1488        AuthPack ::= SEQUENCE {
1489           pkAuthenticator         [0] PKAuthenticator,
1490           clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
1491                    -- Type SubjectPublicKeyInfo is defined in
1492                    -- [RFC3280].
1493                    -- Specifies Diffie-Hellman domain parameters
1494                    -- and the client's public key value [IEEE1363].
1495                    -- The DH public key value is encoded as a BIT
1496                    -- STRING, as specified in Section 2.3.3 of
1497                    -- [RFC3279].
1498                    -- This field is present only if the client wishes
1499                    -- to use the Diffie-Hellman key agreement method.
1500           supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
1501
1502
1503
1504 Tung & Zhu              Expires January 20, 2006               [Page 27]
1505 \f
1506 Internet-Draft                   PKINIT                        July 2005
1507
1508
1509                                       OPTIONAL,
1510                    -- Type AlgorithmIdentifier is defined in
1511                    -- [RFC3280].
1512                    -- List of CMS encryption types supported by the
1513                    -- client in order of (decreasing) preference.
1514           clientDHNonce           [3] DHNonce OPTIONAL,
1515                    -- Present only if the client indicates that it
1516                    -- wishes to reuse DH keys or to allow the KDC to
1517                    -- do so.
1518           ...
1519        }
1520
1521        PKAuthenticator ::= SEQUENCE {
1522           cusec                   [0] INTEGER (0..999999),
1523           ctime                   [1] KerberosTime,
1524                    -- cusec and ctime are used as in [RFC4120], for
1525                    -- replay prevention.
1526           nonce                   [2] INTEGER (0..4294967295),
1527                    -- Chosen randomly;  This nonce does not need to
1528                    -- match with the nonce in the KDC-REQ-BODY.
1529           paChecksum              [3] OCTET STRING,
1530                    -- Contains the SHA1 checksum, performed over
1531                    -- KDC-REQ-BODY.
1532           ...
1533        }
1534
1535        TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
1536                       ExternalPrincipalIdentifier
1537                    -- Identifies a list of CAs trusted by the KDC.
1538                    -- Each ExternalPrincipalIdentifier identifies a CA
1539                    -- or a CA certificate (thereby its public key).
1540
1541        TD-INVALID-CERTIFICATES ::= SEQUENCE OF
1542                       ExternalPrincipalIdentifier
1543                    -- Each ExternalPrincipalIdentifier identifies a
1544                    -- certificate (sent by the client) with an invalid
1545                    -- signature.
1546
1547        KRB5PrincipalName ::= SEQUENCE {
1548            realm                   [0] Realm,
1549            principalName           [1] PrincipalName
1550        }
1551
1552        AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
1553                       ExternalPrincipalIdentifier
1554                    -- Identifies the certification path based on which
1555                    -- the client certificate was validated.
1556                    -- Each ExternalPrincipalIdentifier identifies a CA
1557
1558
1559
1560 Tung & Zhu              Expires January 20, 2006               [Page 28]
1561 \f
1562 Internet-Draft                   PKINIT                        July 2005
1563
1564
1565                    -- or a CA certificate (thereby its public key).
1566
1567        PA-PK-AS-REP ::= CHOICE {
1568           dhInfo                  [0] DHRepInfo,
1569                    -- Selected when Diffie-Hellman key exchange is
1570                    -- used.
1571           encKeyPack              [1] IMPLICIT OCTET STRING,
1572                    -- Selected when public key encryption is used.
1573                    -- Contains a CMS type ContentInfo encoded
1574                    -- according to [RFC3852].
1575                    -- The contentType field of the type ContentInfo is
1576                    -- id-envelopedData (1.2.840.113549.1.7.3).
1577                    -- The content field is an EnvelopedData.
1578                    -- The contentType field for the type EnvelopedData
1579                    -- is id-signedData (1.2.840.113549.1.7.2).
1580                    -- The eContentType field for the inner type
1581                    -- SignedData (when unencrypted) is id-pkrkeydata
1582                    -- (1.2.840.113549.1.7.3) and the eContent field
1583                    -- contains the DER encoding of the type
1584                    -- ReplyKeyPack.
1585                    -- ReplyKeyPack is defined below.
1586           ...
1587        }
1588
1589        DHRepInfo ::= SEQUENCE {
1590           dhSignedData            [0] IMPLICIT OCTET STRING,
1591                    -- Contains a CMS type ContentInfo encoded according
1592                    -- to [RFC3852].
1593                    -- The contentType field of the type ContentInfo is
1594                    -- id-signedData (1.2.840.113549.1.7.2), and the
1595                    -- content field is a SignedData.
1596                    -- The eContentType field for the type SignedData is
1597                    -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
1598                    -- eContent field contains the DER encoding of the
1599                    -- type KDCDHKeyInfo.
1600                    -- KDCDHKeyInfo is defined below.
1601           serverDHNonce           [1] DHNonce OPTIONAL
1602                    -- Present if and only if dhKeyExpiration is
1603                    -- present.
1604        }
1605
1606        KDCDHKeyInfo ::= SEQUENCE {
1607           subjectPublicKey        [0] BIT STRING,
1608                    -- KDC's DH public key.
1609                    -- The DH public key value is encoded as a BIT
1610                    -- STRING, as specified in Section 2.3.3 of
1611                    -- [RFC3279].
1612           nonce                   [1] INTEGER (0..4294967295),
1613
1614
1615
1616 Tung & Zhu              Expires January 20, 2006               [Page 29]
1617 \f
1618 Internet-Draft                   PKINIT                        July 2005
1619
1620
1621                    -- Contains the nonce in the PKAuthenticator of the
1622                    -- request if DH keys are NOT reused,
1623                    -- 0 otherwise.
1624           dhKeyExpiration         [2] KerberosTime OPTIONAL,
1625                    -- Expiration time for KDC's key pair,
1626                    -- present if and only if DH keys are reused. If
1627                    -- this field is omitted then the serverDHNonce
1628                    -- field MUST also be omitted.
1629           ...
1630        }
1631
1632        ReplyKeyPack ::= SEQUENCE {
1633           replyKey                [0] EncryptionKey,
1634                    -- Contains the session key used to encrypt the
1635                    -- enc-part field in the AS-REP.
1636           asChecksum              [1] Checksum,
1637                   -- Contains the checksum of the AS-REQ
1638                   -- corresponding to the containing AS-REP.
1639                   -- The checksum is performed over the type AS-REQ.
1640                   -- The protocol key [RFC3961] of the checksum is the
1641                   -- replyKey and the key usage number is 6.
1642                   -- If the replyKey's enctype is "newer" [RFC4120]
1643                   -- [RFC4121], the checksum is the required
1644                   -- checksum operation [RFC3961] for that enctype.
1645                   -- The client MUST verify this checksum upon receipt
1646                   -- of the AS-REP.
1647           ...
1648        }
1649
1650        TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
1651                    -- Each AlgorithmIdentifier specifies a set of
1652                    -- Diffie-Hellman domain parameters [IEEE1363].
1653                    -- This list is in decreasing preference order.
1654        END
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672 Tung & Zhu              Expires January 20, 2006               [Page 30]
1673 \f
1674 Internet-Draft                   PKINIT                        July 2005
1675
1676
1677 Intellectual Property Statement
1678
1679    The IETF takes no position regarding the validity or scope of any
1680    Intellectual Property Rights or other rights that might be claimed to
1681    pertain to the implementation or use of the technology described in
1682    this document or the extent to which any license under such rights
1683    might or might not be available; nor does it represent that it has
1684    made any independent effort to identify any such rights.  Information
1685    on the procedures with respect to rights in RFC documents can be
1686    found in BCP 78 and BCP 79.
1687
1688    Copies of IPR disclosures made to the IETF Secretariat and any
1689    assurances of licenses to be made available, or the result of an
1690    attempt made to obtain a general license or permission for the use of
1691    such proprietary rights by implementers or users of this
1692    specification can be obtained from the IETF on-line IPR repository at
1693    http://www.ietf.org/ipr.
1694
1695    The IETF invites any interested party to bring to its attention any
1696    copyrights, patents or patent applications, or other proprietary
1697    rights that may cover technology that may be required to implement
1698    this standard.  Please address the information to the IETF at
1699    ietf-ipr@ietf.org.
1700
1701
1702 Disclaimer of Validity
1703
1704    This document and the information contained herein are provided on an
1705    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1706    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1707    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1708    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1709    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1710    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1711
1712
1713 Copyright Statement
1714
1715    Copyright (C) The Internet Society (2005).  This document is subject
1716    to the rights, licenses and restrictions contained in BCP 78, and
1717    except as set forth therein, the authors retain all their rights.
1718
1719
1720 Acknowledgment
1721
1722    Funding for the RFC Editor function is currently provided by the
1723    Internet Society.
1724
1725
1726
1727
1728 Tung & Zhu              Expires January 20, 2006               [Page 31]
1729 \f
1730