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

   1 NETWORK WORKING GROUP                                            B. Tung
   2 Internet-Draft                        USC Information Sciences Institute
   3 Expires: March 16, 2006                                           L. Zhu
   4                                                    Microsoft Corporation
   5                                                       September 12, 2005
   6
   7
   8      Public Key Cryptography for Initial Authentication in Kerberos
   9                    draft-ietf-cat-kerberos-pk-init-28
  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 March 16, 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 March 16, 2006                 [Page 1]
  53 \f
  54 Internet-Draft                   PKINIT                   September 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 . . . . . . . . . . . . . . . . . . . . . . . 23
  75    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
  76    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
  77      7.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
  78      7.2.  Informative References . . . . . . . . . . . . . . . . . . 25
  79    Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 25
  80    Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 31
  81    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
  82    Intellectual Property and Copyright Statements . . . . . . . . . . 34
  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 March 16, 2006                 [Page 2]
 109 \f
 110 Internet-Draft                   PKINIT                   September 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
 152 2.  Conventions Used in This Document
 153
 154    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 155    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 156    document are to be interpreted as described in [RFC2119].
 157
 158    Both the AS and the TGS are referred to as the KDC.
 159
 160    In this document, the encryption key used to encrypt the enc-part
 161
 162
 163
 164 Tung & Zhu               Expires March 16, 2006                 [Page 3]
 165 \f
 166 Internet-Draft                   PKINIT                   September 2005
 167
 168
 169    field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
 170    reply key.
 171
 172
 173 3.  Extensions
 174
 175    This section describes extensions to [RFC4120] for supporting the use
 176    of public-key cryptography in the initial request for a ticket.
 177
 178    Briefly, this document defines the following extensions to [RFC4120]:
 179
 180    1. The client indicates the use of public-key authentication by
 181       including a special preauthenticator in the initial request.  This
 182       preauthenticator contains the client's public-key data and a
 183       signature.
 184
 185    2. The KDC tests the client's request against its authentication
 186       policy and trusted Certification Authorities (CAs).
 187
 188    3. If the request passes the verification tests, the KDC replies as
 189       usual, but the reply is encrypted using either:
 190
 191       a. a key generated through a Diffie-Hellman (DH) key exchange
 192          [RFC2631] [IEEE1363] with the client, signed using the KDC's
 193          signature key; or
 194
 195       b. a symmetric encryption key, signed using the KDC's signature
 196          key and encrypted using the client's public key.
 197
 198       Any keying material required by the client to obtain the
 199       encryption key for decrypting the KDC reply is returned in a pre-
 200       authentication field accompanying the usual reply.
 201
 202    4. The client validates the KDC's signature, obtains the encryption
 203       key, decrypts the reply, and then proceeds as usual.
 204
 205    Section 3.1 of this document enumerates the required algorithms and
 206    necessary extension message types.  Section 3.2 describes the
 207    extension messages in greater detail.
 208
 209 3.1.  Definitions, Requirements, and Constants
 210
 211 3.1.1.  Required Algorithms
 212
 213    All PKINIT implementations MUST support the following algorithms:
 214
 215
 216
 217
 218
 219
 220 Tung & Zhu               Expires March 16, 2006                 [Page 4]
 221 \f
 222 Internet-Draft                   PKINIT                   September 2005
 223
 224
 225    o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
 226       sha1-96 [RFC3962].
 227
 228    o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
 229
 230    o  AS reply key delivery method: Diffie-Hellman key exchange
 231       [RFC2631].
 232
 233    In addition, implementations of this specification MUST be capable of
 234    processing the Extended Key Usage (EKU) extension and the id-pksan
 235    (as defined in Section 3.2.2) otherName of the Subject Alternative
 236    Name (SAN) extension in X.509 certificates [RFC3280], if present.
 237
 238 3.1.2.  Defined Message and Encryption Types
 239
 240    PKINIT makes use of the following new pre-authentication types:
 241
 242        PA_PK_AS_REQ                                 16
 243        PA_PK_AS_REP                                 17
 244
 245    PKINIT also makes use of the following new authorization data type:
 246
 247        AD_INITIAL_VERIFIED_CAS                       9
 248
 249    PKINIT introduces the following new error codes:
 250
 251        KDC_ERR_CLIENT_NOT_TRUSTED                   62
 252        KDC_ERR_INVALID_SIG                          64
 253        KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
 254        KDC_ERR_CANT_VERIFY_CERTIFICATE              70
 255        KDC_ERR_INVALID_CERTIFICATE                  71
 256        KDC_ERR_REVOKED_CERTIFICATE                  72
 257        KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
 258        KDC_ERR_CLIENT_NAME_MISMATCH                 75
 259        KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
 260
 261    PKINIT uses the following typed data types for errors:
 262
 263        TD_TRUSTED_CERTIFIERS                       104
 264        TD_INVALID_CERTIFICATES                     105
 265        TD_DH_PARAMETERS                            109
 266
 267    PKINIT defines the following encryption types, for use in the AS-REQ
 268    message to indicate acceptance of the corresponding algorithms that
 269    can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
 270    the reply:
 271
 272
 273
 274
 275
 276 Tung & Zhu               Expires March 16, 2006                 [Page 5]
 277 \f
 278 Internet-Draft                   PKINIT                   September 2005
 279
 280
 281        dsaWithSHA1-CmsOID                            9
 282        md5WithRSAEncryption-CmsOID                  10
 283        sha1WithRSAEncryption-CmsOID                 11
 284        rc2CBC-EnvOID                                12
 285        rsaEncryption-EnvOID   (PKCS1 v1.5)          13
 286        rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
 287        des-ede3-cbc-EnvOID                          15
 288
 289    The ASN.1 module for all structures defined in this document (plus
 290    IMPORT statements for all imported structures) is given in
 291    Appendix A.
 292
 293    All structures defined in or imported into this document MUST be
 294    encoded using Distinguished Encoding Rules (DER) [X690] (unless
 295    otherwise noted).  All data structures carried in OCTET STRINGs must
 296    be encoded according to the rules specified in corresponding
 297    specifications.
 298
 299    Interoperability note: Some implementations may not be able to decode
 300    wrapped CMS objects encoded with BER but not DER; specifically, they
 301    may not be able to decode infinite length encodings.  To maximize
 302    interoperability, implementers SHOULD encode CMS objects used in
 303    PKINIT with DER.
 304
 305 3.1.3.  Algorithm Identifiers
 306
 307    PKINIT does not define, but does make use of, the following algorithm
 308    identifiers.
 309
 310    PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
 311    key agreement [RFC3279]:
 312
 313        dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
 314
 315    PKINIT uses the following signature algorithm identifiers [RFC3279]:
 316
 317        sha-1WithRSAEncryption (RSA with SHA1)
 318        md5WithRSAEncryption   (RSA with MD5)
 319        id-dsa-with-sha1       (DSA with SHA1)
 320
 321    PKINIT uses the following encryption algorithm identifiers [RFC3447]
 322    for encrypting the temporary key with a public key:
 323
 324        rsaEncryption          (PKCS1 v1.5)
 325        id-RSAES-OAEP          (PKCS1 v2.0)
 326
 327    PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
 328    for encrypting the AS reply key with the temporary key:
 329
 330
 331
 332 Tung & Zhu               Expires March 16, 2006                 [Page 6]
 333 \f
 334 Internet-Draft                   PKINIT                   September 2005
 335
 336
 337        des-ede3-cbc           (three-key 3DES, CBC mode)
 338        rc2-cbc                (RC2, CBC mode)
 339        id-aes256-CBC          (AES-256, CBC mode)
 340
 341 3.2.  PKINIT Pre-authentication Syntax and Use
 342
 343    This section defines the syntax and use of the various pre-
 344    authentication fields employed by PKINIT.
 345
 346 3.2.1.  Generation of Client Request
 347
 348    The initial authentication request (AS-REQ) is sent as per [RFC4120];
 349    in addition, a pre-authentication data element, whose padata-type is
 350    PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
 351    type PA-PK-AS-REQ, is included.
 352
 353        PA-PK-AS-REQ ::= SEQUENCE {
 354           signedAuthPack          [0] IMPLICIT OCTET STRING,
 355                    -- Contains a CMS type ContentInfo encoded
 356                    -- according to [RFC3852].
 357                    -- The contentType field of the type ContentInfo
 358                    -- is id-signedData (1.2.840.113549.1.7.2),
 359                    -- and the content field is a SignedData.
 360                    -- The eContentType field for the type SignedData is
 361                    -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
 362                    -- eContent field contains the DER encoding of the
 363                    -- type AuthPack.
 364                    -- AuthPack is defined below.
 365           trustedCertifiers       [1] SEQUENCE OF
 366                       ExternalPrincipalIdentifier OPTIONAL,
 367                    -- A list of CAs, trusted by the client, that can
 368                    -- be used to certify the KDC.
 369                    -- Each ExternalPrincipalIdentifier identifies a CA
 370                    -- or a CA certificate (thereby its public key).
 371                    -- The information contained in the
 372                    -- trustedCertifiers SHOULD be used by the KDC as
 373                    -- hints to guide its selection of an appropriate
 374                    -- certificate chain to return to the client.
 375           kdcPkId                 [2] IMPLICIT OCTET STRING
 376                                       OPTIONAL,
 377                    -- Contains a CMS type SignerIdentifier encoded
 378                    -- according to [RFC3852].
 379                    -- Identifies, if present, a particular KDC
 380                    -- public key that the client already has.
 381           ...
 382        }
 383
 384        DHNonce ::= OCTET STRING
 385
 386
 387
 388 Tung & Zhu               Expires March 16, 2006                 [Page 7]
 389 \f
 390 Internet-Draft                   PKINIT                   September 2005
 391
 392
 393        ExternalPrincipalIdentifier ::= SEQUENCE {
 394           subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
 395                    -- Contains a PKIX type Name encoded according to
 396                    -- [RFC3280].
 397                    -- Identifies the certificate subject by the
 398                    -- distinguished subject name.
 399                    -- REQUIRED when there is a distinguished subject
 400                    -- name present in the certificate.
 401          issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
 402                    -- Contains a CMS type IssuerAndSerialNumber encoded
 403                    -- according to [RFC3852].
 404                    -- Identifies a certificate of the subject.
 405                    -- REQUIRED for TD-INVALID-CERTIFICATES and
 406                    -- TD-TRUSTED-CERTIFIERS.
 407          subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
 408                    -- Identifies the subject's public key by a key
 409                    -- identifier.  When an X.509 certificate is
 410                    -- referenced, this key identifier matches the X.509
 411                    -- subjectKeyIdentifier extension value.  When other
 412                    -- certificate formats are referenced, the documents
 413                    -- that specify the certificate format and their use
 414                    -- with the CMS must include details on matching the
 415                    -- key identifier to the appropriate certificate
 416                    -- field.
 417                    -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
 418           ...
 419        }
 420
 421        AuthPack ::= SEQUENCE {
 422           pkAuthenticator         [0] PKAuthenticator,
 423           clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
 424                    -- Type SubjectPublicKeyInfo is defined in
 425                    -- [RFC3280].
 426                    -- Specifies Diffie-Hellman domain parameters
 427                    -- and the client's public key value [IEEE1363].
 428                    -- The DH public key value is encoded as a BIT
 429                    -- STRING according to [RFC3279].
 430                    -- This field is present only if the client wishes
 431                    -- to use the Diffie-Hellman key agreement method.
 432           supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
 433                                       OPTIONAL,
 434                    -- Type AlgorithmIdentifier is defined in
 435                    -- [RFC3280].
 436                    -- List of CMS encryption types supported by the
 437                    -- client in order of (decreasing) preference.
 438           clientDHNonce           [3] DHNonce OPTIONAL,
 439                    -- Present only if the client indicates that it
 440                    -- wishes to reuse DH keys or to allow the KDC to
 441
 442
 443
 444 Tung & Zhu               Expires March 16, 2006                 [Page 8]
 445 \f
 446 Internet-Draft                   PKINIT                   September 2005
 447
 448
 449                    -- do so (see Section 3.2.3.1).
 450           ...
 451        }
 452
 453        PKAuthenticator ::= SEQUENCE {
 454           cusec                   [0] INTEGER (0..999999),
 455           ctime                   [1] KerberosTime,
 456                    -- cusec and ctime are used as in [RFC4120], for
 457                    -- replay prevention.
 458           nonce                   [2] INTEGER (0..4294967295),
 459                    -- Chosen randomly;  This nonce does not need to
 460                    -- match with the nonce in the KDC-REQ-BODY.
 461           paChecksum              [3] OCTET STRING,
 462                    -- Contains the SHA1 checksum, performed over
 463                    -- KDC-REQ-BODY.
 464           ...
 465        }
 466
 467    The ContentInfo [RFC3852] structure for the signedAuthPack field is
 468    filled out as follows:
 469
 470    1.  The contentType field of the type ContentInfo is id-signedData
 471        (as defined in [RFC3852]), and the content field is a SignedData
 472        (as defined in [RFC3852]).
 473
 474    2.  The eContentType field for the type SignedData is id-pkauthdata:
 475        { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
 476        pkinit(3) pkauthdata(1) }.
 477
 478    3.  The eContent field for the type SignedData contains the DER
 479        encoding of the type AuthPack.
 480
 481    4.  The signerInfos field of the type SignedData contains a single
 482        signerInfo, which contains the signature over the type AuthPack.
 483
 484    5.  The certificates field of the type SignedData contains
 485        certificates intended to facilitate certification path
 486        construction, so that the KDC can verify the signature over the
 487        type AuthPack.  For path validation, these certificates SHOULD be
 488        sufficient to construct at least one certification path from the
 489        client certificate to one trust anchor acceptable by the KDC
 490        [CAPATH].  The client MUST be capable of including such a set of
 491        certificates if configured to do so.  The certificates field MUST
 492        NOT contain "root" CA certificates.
 493
 494    6.  The client's Diffie-Hellman public value (clientPublicValue) is
 495        included if and only if the client wishes to use the Diffie-
 496        Hellman key agreement method.  The Diffie-Hellman domain
 497
 498
 499
 500 Tung & Zhu               Expires March 16, 2006                 [Page 9]
 501 \f
 502 Internet-Draft                   PKINIT                   September 2005
 503
 504
 505        parameters [IEEE1363] for the client's public key are specified
 506        in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
 507        and the client's Diffie-Hellman public key value is mapped to a
 508        subjectPublicKey (a BIT STRING) according to [RFC3279].  When
 509        using the Diffie-Hellman key agreement method, implementations
 510        MUST support Oakley 1024-bit Modular Exponential (MODP) well-
 511        known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
 512        14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
 513        group 16 [RFC3526].
 514
 515        The Diffie-Hellman field size should be chosen so as to provide
 516        sufficient cryptographic security [RFC3766].
 517
 518        When MODP Diffie-Hellman is used, the exponents should have at
 519        least twice as many bits as the symmetric keys that will be
 520        derived from them [ODL99].
 521
 522    7.  The client may wish to reuse DH keys or to allow the KDC to do so
 523        (see Section 3.2.3.1).  If so, then the client includes the
 524        clientDHNonce field.  This nonce string needs to be as long as
 525        the longest key length of the symmetric key types that the client
 526        supports.  This nonce MUST be chosen randomly.
 527
 528
 529 3.2.2.  Receipt of Client Request
 530
 531    Upon receiving the client's request, the KDC validates it.  This
 532    section describes the steps that the KDC MUST (unless otherwise
 533    noted) take in validating the request.
 534
 535    The KDC verifies the client's signature in the signedAuthPack field
 536    according to [RFC3852].
 537
 538    If, while validating the client's X.509 certificate [RFC3280], the
 539    KDC cannot build a certification path to validate the client's
 540    certificate, it sends back a KRB-ERROR [RFC4120] message with the
 541    code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
 542    this error message is a TYPED-DATA (as defined in [RFC4120]) that
 543    contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
 544    whose data-value contains the DER encoding of the type TD-TRUSTED-
 545    CERTIFIERS:
 546
 547        TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
 548                       ExternalPrincipalIdentifier
 549                    -- Identifies a list of CAs trusted by the KDC.
 550                    -- Each ExternalPrincipalIdentifier identifies a CA
 551                    -- or a CA certificate (thereby its public key).
 552
 553
 554
 555
 556 Tung & Zhu               Expires March 16, 2006                [Page 10]
 557 \f
 558 Internet-Draft                   PKINIT                   September 2005
 559
 560
 561    Upon receiving this error message, the client SHOULD retry only if it
 562    has a different set of certificates (from those of the previous
 563    requests) that form a certification path (or a partial path) from one
 564    of the trust anchors acceptable by the KDC to its own certificate.
 565
 566    If, while processing the certification path, the KDC determines that
 567    the signature on one of the certificates in the signedAuthPack field
 568    is invalid, it returns a KRB-ERROR [RFC4120] message with the code
 569    KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
 570    message is a TYPED-DATA that contains an element whose data-type is
 571    TD_INVALID_CERTIFICATES, and whose data-value contains the DER
 572    encoding of the type TD-INVALID-CERTIFICATES:
 573
 574        TD-INVALID-CERTIFICATES ::= SEQUENCE OF
 575                       ExternalPrincipalIdentifier
 576                    -- Each ExternalPrincipalIdentifier identifies a
 577                    -- certificate (sent by the client) with an invalid
 578                    -- signature.
 579
 580    If more than one X.509 certificate signature is invalid, the KDC MAY
 581    include one IssuerAndSerialNumber per invalid signature within the
 582    TD-INVALID-CERTIFICATES.
 583
 584    The client's X.509 certificate is validated according to [RFC3280].
 585
 586    Based on local policy, the KDC may also check whether any X.509
 587    certificates in the certification path validating the client's
 588    certificate have been revoked.  If any of them have been revoked, the
 589    KDC MUST return an error message with the code
 590    KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
 591    revocation status but is unable to do so, it SHOULD return an error
 592    message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
 593    certificate or certificates affected are identified exactly as for
 594    the error code KDC_ERR_INVALID_CERTIFICATE (see above).
 595
 596    Note that the TD_INVALID_CERTIFICATES error data is only used to
 597    identify invalid certificates sent by the client in the request.
 598
 599    The client's public key is then used to verify the signature.  If the
 600    signature fails to verify, the KDC MUST return an error message with
 601    the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
 602    this error message.
 603
 604    In addition to validating the client's signature, the KDC MUST also
 605    check that the client's public key used to verify the client's
 606    signature is bound to the client's principal name as specified in the
 607    AS-REQ as follows:
 608
 609
 610
 611
 612 Tung & Zhu               Expires March 16, 2006                [Page 11]
 613 \f
 614 Internet-Draft                   PKINIT                   September 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 March 16, 2006                [Page 12]
 669 \f
 670 Internet-Draft                   PKINIT                   September 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 March 16, 2006                [Page 13]
 725 \f
 726 Internet-Draft                   PKINIT                   September 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 March 16, 2006                [Page 14]
 781 \f
 782 Internet-Draft                   PKINIT                   September 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 according to [RFC3279].
 823           nonce                   [1] INTEGER (0..4294967295),
 824                    -- Contains the nonce in the PKAuthenticator of the
 825                    -- request if DH keys are NOT reused,
 826                    -- 0 otherwise.
 827           dhKeyExpiration         [2] KerberosTime OPTIONAL,
 828                    -- Expiration time for KDC's key pair,
 829                    -- present if and only if DH keys are reused. If
 830                    -- this field is omitted then the serverDHNonce
 831                    -- field MUST also be omitted. See Section 3.2.3.1.
 832           ...
 833
 834
 835
 836 Tung & Zhu               Expires March 16, 2006                [Page 15]
 837 \f
 838 Internet-Draft                   PKINIT                   September 2005
 839
 840
 841        }
 842
 843 3.2.3.1.  Using Diffie-Hellman Key Exchange
 844
 845    In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
 846
 847    The ContentInfo [RFC3852] structure for the dhSignedData field is
 848    filled in as follows:
 849
 850    1.  The contentType field of the type ContentInfo is id-signedData
 851        (as defined in [RFC3852]), and the content field is a SignedData
 852        (as defined in [RFC3852]).
 853
 854    2.  The eContentType field for the type SignedData is the OID value
 855        for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
 856        security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
 857
 858    3.  The eContent field for the type SignedData contains the DER
 859        encoding of the type KDCDHKeyInfo.
 860
 861    4.  The signerInfos field of the type SignedData contains a single
 862        signerInfo, which contains the signature over the type
 863        KDCDHKeyInfo.
 864
 865    5.  The certificates field of the type SignedData contains
 866        certificates intended to facilitate certification path
 867        construction, so that the client can verify the KDC's signature
 868        over the type KDCDHKeyInfo.  The information contained in the
 869        trustedCertifiers in the request SHOULD be used by the KDC as
 870        hints to guide its selection of an appropriate certificate chain
 871        to return to the client.  This field may only. be left empty if
 872        the KDC public key specified by the kdcPkId field in the PA-PK-
 873        AS-REQ was used for signing.  Otherwise, for path validation,
 874        these certificates SHOULD be sufficient to construct at least one
 875        certification path from the KDC certificate to one trust anchor
 876        acceptable by the client [CAPATH].  The KDC MUST be capable of
 877        including such a set of certificates if configured to do so.  The
 878        certificates field MUST NOT contain "root" CA certificates.
 879
 880    6.  If the client included the clientDHNonce field, then the KDC may
 881        choose to reuse its DH keys (see Section 3.2.3.1).  If the server
 882        reuses DH keys then it MUST include an expiration time in the
 883        dhKeyExpiration field.  Past the point of the expiration time,
 884        the signature over the type DHRepInfo is considered expired/
 885        invalid.  When the server reuses DH keys then it MUST include a
 886        serverDHNonce at least as long as the length of keys for the
 887        symmetric encryption system used to encrypt the AS reply.  Note
 888        that including the serverDHNonce changes how the client and
 889
 890
 891
 892 Tung & Zhu               Expires March 16, 2006                [Page 16]
 893 \f
 894 Internet-Draft                   PKINIT                   September 2005
 895
 896
 897        server calculate the key to use to encrypt the reply; see below
 898        for details.  The KDC SHOULD NOT reuse DH keys unless the
 899        clientDHNonce field is present in the request.
 900
 901    The AS reply key is derived as follows:
 902
 903    1. Both the KDC and the client calculate the shared secret value as
 904       follows:
 905
 906       a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
 907          shared secret value.  DHSharedSecret is the value ZZ as
 908          described in Section 2.1.1 of [RFC2631].
 909
 910       DHSharedSecret is first padded with leading zeros such that the
 911       size of DHSharedSecret in octets is the same as that of the
 912       modulus, then represented as a string of octets in big-endian
 913       order.
 914
 915       Implementation note: Both the client and the KDC can cache the
 916       triple (ya, yb, DHSharedSecret), where ya is the client's public
 917       key and yb is the KDC's public key.  If both ya and yb are the
 918       same in a later exchange, the cached DHSharedSecret can be used.
 919
 920    2. Let K be the key-generation seed length [RFC3961] of the AS reply
 921       key whose enctype is selected according to [RFC4120].
 922
 923    3. Define the function octetstring2key() as follows:
 924
 925            octetstring2key(x) == random-to-key(K-truncate(
 926                                     SHA1(0x00 | x) |
 927                                     SHA1(0x01 | x) |
 928                                     SHA1(0x02 | x) |
 929                                     ...
 930                                     ))
 931
 932       where x is an octet string; | is the concatenation operator; 0x00,
 933       0x01, 0x02, etc., are each represented as a single octet; random-
 934       to-key() is an operation that generates a protocol key from a
 935       bitstring of length K; and K-truncate truncates its input to the
 936       first K bits.  Both K and random-to-key() are as defined in the
 937       kcrypto profile [RFC3961] for the enctype of the AS reply key.
 938
 939    4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
 940       the serverDHNonce; otherwise, let both n_c and n_k be empty octet
 941       strings.
 942
 943
 944
 945
 946
 947
 948 Tung & Zhu               Expires March 16, 2006                [Page 17]
 949 \f
 950 Internet-Draft                   PKINIT                   September 2005
 951
 952
 953    5. The AS reply key k is:
 954
 955            k = octetstring2key(DHSharedSecret | n_c | n_k)
 956
 957 3.2.3.2.  Using Public Key Encryption
 958
 959    In this case, the PA-PK-AS-REP contains a ContentInfo structure
 960    wrapped in an OCTET STRING.  The AS reply key is encrypted in the
 961    encKeyPack field, which contains data of type ReplyKeyPack:
 962
 963        ReplyKeyPack ::= SEQUENCE {
 964           replyKey                [0] EncryptionKey,
 965                    -- Contains the session key used to encrypt the
 966                    -- enc-part field in the AS-REP.
 967           asChecksum              [1] Checksum,
 968                   -- Contains the checksum of the AS-REQ
 969                   -- corresponding to the containing AS-REP.
 970                   -- The checksum is performed over the type AS-REQ.
 971                   -- The protocol key [RFC3961] of the checksum is the
 972                   -- replyKey and the key usage number is 6.
 973                   -- If the replyKey's enctype is "newer" [RFC4120]
 974                   -- [RFC4121], the checksum is the required
 975                   -- checksum operation [RFC3961] for that enctype.
 976                   -- The client MUST verify this checksum upon receipt
 977                   -- of the AS-REP.
 978           ...
 979        }
 980
 981    The ContentInfo [RFC3852] structure for the encKeyPack field is
 982    filled in as follows:
 983
 984    1.  The contentType field of the type ContentInfo is id-envelopedData
 985        (as defined in [RFC3852]), and the content field is an
 986        EnvelopedData (as defined in [RFC3852]).
 987
 988    2.  The contentType field for the type EnvelopedData is id-
 989        signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
 990        pkcs (1) pkcs7 (7) signedData (2) }.
 991
 992    3.  The eContentType field for the inner type SignedData (when
 993        decrypted from the encryptedContent field for the type
 994        EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
 995        internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
 996
 997    4.  The eContent field for the inner type SignedData contains the DER
 998        encoding of the type ReplyKeyPack.
 999
1000
1001
1002
1003
1004 Tung & Zhu               Expires March 16, 2006                [Page 18]
1005 \f
1006 Internet-Draft                   PKINIT                   September 2005
1007
1008
1009    5.  The signerInfos field of the inner type SignedData contains a
1010        single signerInfo, which contains the signature over the type
1011        ReplyKeyPack.
1012
1013    6.  The certificates field of the inner type SignedData contains
1014        certificates intended to facilitate certification path
1015        construction, so that the client can verify the KDC's signature
1016        over the type ReplyKeyPack.  The information contained in the
1017        trustedCertifiers in the request SHOULD be used by the KDC as
1018        hints to guide its selection of an appropriate certificate chain
1019        to return to the client.  This field may only be left empty if
1020        the KDC public key specified by the kdcPkId field in the PA-PK-
1021        AS-REQ was used for signing.  Otherwise, for path validation,
1022        these certificates SHOULD be sufficient to construct at least one
1023        certification path from the KDC certificate to one trust anchor
1024        acceptable by the client [CAPATH].  The KDC MUST be capable of
1025        including such a set of certificates if configured to do so.  The
1026        certificates field MUST NOT contain "root" CA certificates.
1027
1028    7.  The recipientInfos field of the type EnvelopedData is a SET which
1029        MUST contain exactly one member of type KeyTransRecipientInfo.
1030        The encryptedKey of this member contains the temporary key which
1031        is encrypted using the client's public key.
1032
1033    8.  The unprotectedAttrs or originatorInfo fields of the type
1034        EnvelopedData MAY be present.
1035
1036    Implementations of this RSA encryption key delivery method are
1037    RECOMMENDED to support for RSA keys at least 2048 bits in size.
1038
1039 3.2.4.  Receipt of KDC Reply
1040
1041    Upon receipt of the KDC's reply, the client proceeds as follows.  If
1042    the PA-PK-AS-REP contains the dhSignedData field, the client derives
1043    the AS reply key using the same procedure used by the KDC as defined
1044    in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
1045    field, and the client decrypts and extracts the temporary key in the
1046    encryptedKey field of the member KeyTransRecipientInfo, and then uses
1047    that as the AS reply key.
1048
1049    If the public key encrytion method is used, the client MUST verify
1050    the asChecksum contained in the ReplyKeyPack.
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 March 16, 2006                [Page 19]
1061 \f
1062 Internet-Draft                   PKINIT                   September 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    Unless the client knows by some other means that the KDC certificate
1072    is intended for a Kerberos KDC, the client MUST require that the KDC
1073    certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
1074
1075        id-pkkdcekuoid OBJECT IDENTIFIER ::=
1076          { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1077            pkinit(3) pkkdcekuoid(5) }
1078               -- Signing KDC responses.
1079               -- Key usage bits that MUST be consistent:
1080               -- digitalSignature.
1081
1082    If the KDC certificate contains the Kerberos TGS name encoded as an
1083    id-pksan SAN, this certificate is certified by the issuing CA as a
1084    KDC certificate, therefore the id-pkkdcekuoid EKU is not required.
1085
1086    If all applicable checks are satisfied, the client then decrypts the
1087    enc-part field of the KDC-REP in the AS-REP using the AS reply key,
1088    and then proceeds as described in [RFC4120].
1089
1090    Implementation note: CAs issuing KDC certificates SHOULD place all
1091    "short" and "fully-qualified" Kerberos realm names of the KDC (one
1092    per GeneralName [RFC3280]) into the KDC certificate to allow maximum
1093    flexibility.
1094
1095 3.3.  Interoperability Requirements
1096
1097    The client MUST be capable of sending a set of certificates
1098    sufficient to allow the KDC to construct a certification path for the
1099    client's certificate, if the correct set of certificates is provided
1100    through configuration or policy.
1101
1102    If the client sends all the X.509 certificates on a certification
1103    path to a trust anchor acceptable by the KDC, and the KDC can not
1104    verify the client's public key otherwise, the KDC MUST be able to
1105    process path validation for the client's certificate based on the
1106    certificates in the request.
1107
1108    The KDC MUST be capable of sending a set of certificates sufficient
1109    to allow the client to construct a certification path for the KDC's
1110    certificate, if the correct set of certificates is provided through
1111    configuration or policy.
1112
1113
1114
1115
1116 Tung & Zhu               Expires March 16, 2006                [Page 20]
1117 \f
1118 Internet-Draft                   PKINIT                   September 2005
1119
1120
1121    If the KDC sends all the X.509 certificates on a certification path
1122    to a trust anchor acceptable by the client, and the client can not
1123    verify the KDC's public key otherwise, the client MUST be able to
1124    process path validation for the KDC's certificate based on the
1125    certificates in the reply.
1126
1127 3.4.  KDC Indication of PKINIT Support
1128
1129    If pre-authentication is required, but was not present in the
1130    request, per [RFC4120] an error message with the code
1131    KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
1132    stored in the e-data field of the KRB-ERROR message to specify which
1133    pre-authentication mechanisms are acceptable.  The KDC can then
1134    indicate the support of PKINIT by including an empty element whose
1135    padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
1136
1137    Otherwise if it is required by the KDC's local policy that the client
1138    must be pre-authenticated using the pre-authentication mechanism
1139    specified in this document, but no PKINIT pre-authentication was
1140    present in the request, an error message with the code
1141    KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1142
1143    KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
1144    the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1145    STRING), and clients MUST ignore this and any other value.  Future
1146    extensions to this protocol may specify other data to send instead of
1147    an empty OCTET STRING.
1148
1149
1150 4.  Security Considerations
1151
1152    The symmetric reply key size and Diffie-Hellman field size or RSA
1153    modulus size should be chosen so as to provide sufficient
1154    cryptographic security [RFC3766].
1155
1156    When MODP Diffie-Hellman is used, the exponents should have at least
1157    twice as many bits as the symmetric keys that will be derived from
1158    them [ODL99].
1159
1160    PKINIT raises certain security considerations beyond those that can
1161    be regulated strictly in protocol definitions.  We will address them
1162    in this section.
1163
1164    PKINIT extends the cross-realm model to the public-key
1165    infrastructure.  Users of PKINIT must understand security policies
1166    and procedures appropriate to the use of Public Key Infrastructures
1167    [RFC3280].
1168
1169
1170
1171
1172 Tung & Zhu               Expires March 16, 2006                [Page 21]
1173 \f
1174 Internet-Draft                   PKINIT                   September 2005
1175
1176
1177    In order to trust a KDC certificate that is certified by a CA as a
1178    KDC certificate for a target realm (for example, by asserting the TGS
1179    name of that Kerberos realm as an id-pksan SAN and/or restricting the
1180    certificate usage by using the id-pkkdcekuoid EKU, as described in
1181    Section 3.2.4), the client MUST verify that the KDC certificate's
1182    issuing CA is authorized to issue KDC certificates for that target
1183    realm.  Otherwise, the binding between the KDC certificate and the
1184    KDC of the target realm is not established.
1185
1186    How to validate this authorization is a matter of local policy.  A
1187    way to achieve this is the configuration of specific sets of
1188    intermediary CAs and trust anchors, one of which must be on the KDC
1189    certificate's certification path [RFC3280]; and for each CA or trust
1190    anchor the realms for which it is allowed to issue certificates.
1191
1192    In addition, if any CA is trusted to issue KDC certificates can also
1193    issue other kinds of certificates, then local policy must be able to
1194    distinguish between them: for example, it could require that KDC
1195    certificates contain the id-pkkdcekuoid EKU or that the realm be
1196    specified with the id-pksan SAN.
1197
1198    It is the responsibility of the PKI administrators for an
1199    organization to ensure that KDC certificates are only issued to KDCs,
1200    and that clients can ascertain this using their local policy.
1201
1202    Standard Kerberos allows the possibility of interactions between
1203    cryptosystems of varying strengths; this document adds interactions
1204    with public-key cryptosystems to Kerberos.  Some administrative
1205    policies may allow the use of relatively weak public keys.  Using
1206    such keys to wrap data encrypted under stronger conventional
1207    cryptosystems may be inappropriate.
1208
1209    PKINIT requires keys for symmetric cryptosystems to be generated.
1210    Some such systems contain "weak" keys.  For recommendations regarding
1211    these weak keys, see [RFC4120].
1212
1213    PKINIT allows the use of the same RSA key pair for encryption and
1214    signing when doing RSA encryption based key delivery.  This is not
1215    recommended usage of RSA keys [RFC3447], by using DH based key
1216    delivery this is avoided.
1217
1218    Care should be taken in how certificates are chosen for the purposes
1219    of authentication using PKINIT.  Some local policies may require that
1220    key escrow be used for certain certificate types.  Deployers of
1221    PKINIT should be aware of the implications of using certificates that
1222    have escrowed keys for the purposes of authentication.  Because
1223    signing only certificates are normally not escrowed, by using DH
1224    based key delivery this is avoided.
1225
1226
1227
1228 Tung & Zhu               Expires March 16, 2006                [Page 22]
1229 \f
1230 Internet-Draft                   PKINIT                   September 2005
1231
1232
1233    PKINIT does not provide for a "return routability" test to prevent
1234    attackers from mounting a denial-of-service attack on the KDC by
1235    causing it to perform unnecessary and expensive public-key
1236    operations.  Strictly speaking, this is also true of standard
1237    Kerberos, although the potential cost is not as great, because
1238    standard Kerberos does not make use of public-key cryptography.  By
1239    using DH based key delivery and reusing DH keys, the necessary crypto
1240    processing cost per request can be minimized.
1241
1242    The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1243    permit empty SEQUENCEs to be encoded.  Such empty sequences may only
1244    be used if the KDC itself vouches for the user's certificate.
1245
1246
1247 5.  Acknowledgements
1248
1249    The following people have made significant contributions to this
1250    draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
1251    Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
1252    Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
1253    Jaganathan, Chaskiel M Grundman, Stefan Santesson, Andre Scedrov and
1254    Aaron D. Jaggard.
1255
1256    Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
1257    Jonathan Trostle who wrote earlier versions of this document.
1258
1259    The authors are indebted to the Kerberos working group chair Jeffrey
1260    Hutzelman who kept track of various issues and was enormously helpful
1261    during the creation of this document.
1262
1263    Some of the ideas on which this document is based arose during
1264    discussions over several years between members of the SAAG, the IETF
1265    CAT working group, and the PSRG, regarding integration of Kerberos
1266    and SPX.  Some ideas have also been drawn from the DASS system.
1267    These changes are by no means endorsed by these groups.  This is an
1268    attempt to revive some of the goals of those groups, and this
1269    document approaches those goals primarily from the Kerberos
1270    perspective.
1271
1272    Lastly, comments from groups working on similar ideas in DCE have
1273    been invaluable.
1274
1275
1276 6.  IANA Considerations
1277
1278    This document has no actions for IANA.
1279
1280
1281
1282
1283
1284 Tung & Zhu               Expires March 16, 2006                [Page 23]
1285 \f
1286 Internet-Draft                   PKINIT                   September 2005
1287
1288
1289 7.  References
1290
1291 7.1.  Normative References
1292
1293    [IEEE1363]
1294               IEEE, "Standard Specifications for Public Key
1295               Cryptography", IEEE 1363, 2000.
1296
1297    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1298               Requirement Levels", BCP 14, RFC 2119, March 1997.
1299
1300    [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
1301               RFC 2412, November 1998.
1302
1303    [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
1304               RFC 2631, June 1999.
1305
1306    [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
1307               Identifiers for the Internet X.509 Public Key
1308               Infrastructure Certificate and Certificate Revocation List
1309               (CRL) Profile", RFC 3279, April 2002.
1310
1311    [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
1312               X.509 Public Key Infrastructure Certificate and
1313               Certificate Revocation List (CRL) Profile", RFC 3280,
1314               April 2002.
1315
1316    [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
1317               Algorithms", RFC 3370, August 2002.
1318
1319    [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1320               Standards (PKCS) #1: RSA Cryptography Specifications
1321               Version 2.1", RFC 3447, February 2003.
1322
1323    [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1324               Diffie-Hellman groups for Internet Key Exchange (IKE)",
1325               RFC 3526, May 2003.
1326
1327    [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
1328               Encryption Algorithm in Cryptographic Message Syntax
1329               (CMS)", RFC 3565, July 2003.
1330
1331    [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
1332               Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1333               RFC 3766, April 2004.
1334
1335    [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
1336               RFC 3852, July 2004.
1337
1338
1339
1340 Tung & Zhu               Expires March 16, 2006                [Page 24]
1341 \f
1342 Internet-Draft                   PKINIT                   September 2005
1343
1344
1345    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
1346               Kerberos 5", RFC 3961, February 2005.
1347
1348    [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
1349               Encryption for Kerberos 5", RFC 3962, February 2005.
1350
1351    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1352               Kerberos Network Authentication Service (V5)", RFC 4120,
1353               July 2005.
1354
1355    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
1356               Version 5 Generic Security Service Application Program
1357               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
1358               July 2005.
1359
1360    [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication
1361               Framework.  1997.
1362
1363    [X690]     ASN.1 encoding rules: Specification of Basic Encoding
1364               Rules (BER), Canonical Encoding Rules (CER) and
1365               Distinguished Encoding Rules (DER), ITU-T Recommendation
1366               X.690 (1997) | ISO/IEC International Standard
1367               8825-1:1998.
1368
1369 7.2.  Informative References
1370
1371    [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
1372               pkix-certpathbuild.  Work in Progress.
1373
1374    [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1375               Sizes", Journal of Cryptology 14 (2001) 255-293.
1376
1377    [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
1378               future, Designs, Codes, and Cryptography (1999)".
1379
1380 Appendix A.  PKINIT ASN.1 Module
1381
1382        KerberosV5-PK-INIT-SPEC {
1383                iso(1) identified-organization(3) dod(6) internet(1)
1384                security(5) kerberosV5(2) modules(4) pkinit(5)
1385        } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1386
1387        IMPORTS
1388
1389
1390
1391 Tung & Zhu               Expires March 16, 2006                [Page 25]
1392 \f
1393 Internet-Draft                   PKINIT                   September 2005
1394
1395
1396            SubjectPublicKeyInfo, AlgorithmIdentifier
1397                FROM PKIX1Explicit88 { iso (1)
1398                  identified-organization (3) dod (6) internet (1)
1399                  security (5) mechanisms (5) pkix (7) id-mod (0)
1400                  id-pkix1-explicit (18) }
1401                  -- As defined in RFC 3280.
1402
1403            KerberosTime, PrincipalName, Realm, EncryptionKey
1404                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1405                  dod(6) internet(1) security(5) kerberosV5(2)
1406                  modules(4) krb5spec2(2) } ;
1407
1408        id-pkinit OBJECT IDENTIFIER ::=
1409          { iso (1) org (3) dod (6) internet (1) security (5)
1410            kerberosv5 (2) pkinit (3) }
1411
1412        id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
1413        id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
1414        id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
1415        id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
1416        id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
1417
1418        id-pksan OBJECT IDENTIFIER ::=
1419          { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1420            x509-sanan (2) }
1421
1422        pa-pk-as-req INTEGER ::=                  16
1423        pa-pk-as-rep INTEGER ::=                  17
1424
1425        ad-initial-verified-cas INTEGER ::=        9
1426
1427        td-trusted-certifiers INTEGER ::=        104
1428        td-invalid-certificates INTEGER ::=      105
1429        td-dh-parameters INTEGER ::=             109
1430
1431        PA-PK-AS-REQ ::= SEQUENCE {
1432           signedAuthPack          [0] IMPLICIT OCTET STRING,
1433                    -- Contains a CMS type ContentInfo encoded
1434                    -- according to [RFC3852].
1435                    -- The contentType field of the type ContentInfo
1436                    -- is id-signedData (1.2.840.113549.1.7.2),
1437                    -- and the content field is a SignedData.
1438                    -- The eContentType field for the type SignedData is
1439                    -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
1440                    -- eContent field contains the DER encoding of the
1441                    -- type AuthPack.
1442                    -- AuthPack is defined below.
1443           trustedCertifiers       [1] SEQUENCE OF
1444
1445
1446
1447 Tung & Zhu               Expires March 16, 2006                [Page 26]
1448 \f
1449 Internet-Draft                   PKINIT                   September 2005
1450
1451
1452                       ExternalPrincipalIdentifier OPTIONAL,
1453                    -- A list of CAs, trusted by the client, that can
1454                    -- be used to certify the KDC.
1455                    -- Each ExternalPrincipalIdentifier identifies a CA
1456                    -- or a CA certificate (thereby its public key).
1457                    -- The information contained in the
1458                    -- trustedCertifiers SHOULD be used by the KDC as
1459                    -- hints to guide its selection of an appropriate
1460                    -- certificate chain to return to the client.
1461           kdcPkId                 [2] IMPLICIT OCTET STRING
1462                                       OPTIONAL,
1463                    -- Contains a CMS type SignerIdentifier encoded
1464                    -- according to [RFC3852].
1465                    -- Identifies, if present, a particular KDC
1466                    -- public key that the client already has.
1467           ...
1468        }
1469
1470        DHNonce ::= OCTET STRING
1471
1472        ExternalPrincipalIdentifier ::= SEQUENCE {
1473           subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
1474                    -- Contains a PKIX type Name encoded according to
1475                    -- [RFC3280].
1476                    -- Identifies the certificate subject by the
1477                    -- distinguished subject name.
1478                    -- REQUIRED when there is a distinguished subject
1479                    -- name present in the certificate.
1480          issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
1481                    -- Contains a CMS type IssuerAndSerialNumber encoded
1482                    -- according to [RFC3852].
1483                    -- Identifies a certificate of the subject.
1484                    -- REQUIRED for TD-INVALID-CERTIFICATES and
1485                    -- TD-TRUSTED-CERTIFIERS.
1486          subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
1487                    -- Identifies the subject's public key by a key
1488                    -- identifier.  When an X.509 certificate is
1489                    -- referenced, this key identifier matches the X.509
1490                    -- subjectKeyIdentifier extension value.  When other
1491                    -- certificate formats are referenced, the documents
1492                    -- that specify the certificate format and their use
1493                    -- with the CMS must include details on matching the
1494                    -- key identifier to the appropriate certificate
1495                    -- field.
1496                    -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
1497           ...
1498        }
1499
1500
1501
1502
1503 Tung & Zhu               Expires March 16, 2006                [Page 27]
1504 \f
1505 Internet-Draft                   PKINIT                   September 2005
1506
1507
1508        AuthPack ::= SEQUENCE {
1509           pkAuthenticator         [0] PKAuthenticator,
1510           clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
1511                    -- Type SubjectPublicKeyInfo is defined in
1512                    -- [RFC3280].
1513                    -- Specifies Diffie-Hellman domain parameters
1514                    -- and the client's public key value [IEEE1363].
1515                    -- The DH public key value is encoded as a BIT
1516                    -- STRING according to [RFC3279].
1517                    -- This field is present only if the client wishes
1518                    -- to use the Diffie-Hellman key agreement method.
1519           supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
1520                                       OPTIONAL,
1521                    -- Type AlgorithmIdentifier is defined in
1522                    -- [RFC3280].
1523                    -- List of CMS encryption types supported by the
1524                    -- client in order of (decreasing) preference.
1525           clientDHNonce           [3] DHNonce OPTIONAL,
1526                    -- Present only if the client indicates that it
1527                    -- wishes to reuse DH keys or to allow the KDC to
1528                    -- do so.
1529           ...
1530        }
1531
1532        PKAuthenticator ::= SEQUENCE {
1533           cusec                   [0] INTEGER (0..999999),
1534           ctime                   [1] KerberosTime,
1535                    -- cusec and ctime are used as in [RFC4120], for
1536                    -- replay prevention.
1537           nonce                   [2] INTEGER (0..4294967295),
1538                    -- Chosen randomly;  This nonce does not need to
1539                    -- match with the nonce in the KDC-REQ-BODY.
1540           paChecksum              [3] OCTET STRING,
1541                    -- Contains the SHA1 checksum, performed over
1542                    -- KDC-REQ-BODY.
1543           ...
1544        }
1545
1546        TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
1547                       ExternalPrincipalIdentifier
1548                    -- Identifies a list of CAs trusted by the KDC.
1549                    -- Each ExternalPrincipalIdentifier identifies a CA
1550                    -- or a CA certificate (thereby its public key).
1551
1552        TD-INVALID-CERTIFICATES ::= SEQUENCE OF
1553                       ExternalPrincipalIdentifier
1554                    -- Each ExternalPrincipalIdentifier identifies a
1555                    -- certificate (sent by the client) with an invalid
1556
1557
1558
1559 Tung & Zhu               Expires March 16, 2006                [Page 28]
1560 \f
1561 Internet-Draft                   PKINIT                   September 2005
1562
1563
1564                    -- signature.
1565
1566        KRB5PrincipalName ::= SEQUENCE {
1567            realm                   [0] Realm,
1568            principalName           [1] PrincipalName
1569        }
1570
1571        AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
1572                       ExternalPrincipalIdentifier
1573                    -- Identifies the certification path based on which
1574                    -- the client certificate was validated.
1575                    -- Each ExternalPrincipalIdentifier identifies a CA
1576                    -- or a CA certificate (thereby its public key).
1577
1578        PA-PK-AS-REP ::= CHOICE {
1579           dhInfo                  [0] DHRepInfo,
1580                    -- Selected when Diffie-Hellman key exchange is
1581                    -- used.
1582           encKeyPack              [1] IMPLICIT OCTET STRING,
1583                    -- Selected when public key encryption is used.
1584                    -- Contains a CMS type ContentInfo encoded
1585                    -- according to [RFC3852].
1586                    -- The contentType field of the type ContentInfo is
1587                    -- id-envelopedData (1.2.840.113549.1.7.3).
1588                    -- The content field is an EnvelopedData.
1589                    -- The contentType field for the type EnvelopedData
1590                    -- is id-signedData (1.2.840.113549.1.7.2).
1591                    -- The eContentType field for the inner type
1592                    -- SignedData (when unencrypted) is id-pkrkeydata
1593                    -- (1.2.840.113549.1.7.3) and the eContent field
1594                    -- contains the DER encoding of the type
1595                    -- ReplyKeyPack.
1596                    -- ReplyKeyPack is defined below.
1597           ...
1598        }
1599
1600        DHRepInfo ::= SEQUENCE {
1601           dhSignedData            [0] IMPLICIT OCTET STRING,
1602                    -- Contains a CMS type ContentInfo encoded according
1603                    -- to [RFC3852].
1604                    -- The contentType field of the type ContentInfo is
1605                    -- id-signedData (1.2.840.113549.1.7.2), and the
1606                    -- content field is a SignedData.
1607                    -- The eContentType field for the type SignedData is
1608                    -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
1609                    -- eContent field contains the DER encoding of the
1610                    -- type KDCDHKeyInfo.
1611                    -- KDCDHKeyInfo is defined below.
1612
1613
1614
1615 Tung & Zhu               Expires March 16, 2006                [Page 29]
1616 \f
1617 Internet-Draft                   PKINIT                   September 2005
1618
1619
1620           serverDHNonce           [1] DHNonce OPTIONAL
1621                    -- Present if and only if dhKeyExpiration is
1622                    -- present.
1623        }
1624
1625        KDCDHKeyInfo ::= SEQUENCE {
1626           subjectPublicKey        [0] BIT STRING,
1627                    -- KDC's DH public key.
1628                    -- The DH public key value is encoded as a BIT
1629                    -- STRING according to [RFC3279].
1630            nonce                   [1] INTEGER (0..4294967295),
1631                    -- Contains the nonce in the PKAuthenticator of the
1632                    -- request if DH keys are NOT reused,
1633                    -- 0 otherwise.
1634           dhKeyExpiration         [2] KerberosTime OPTIONAL,
1635                    -- Expiration time for KDC's key pair,
1636                    -- present if and only if DH keys are reused. If
1637                    -- this field is omitted then the serverDHNonce
1638                    -- field MUST also be omitted.
1639           ...
1640        }
1641
1642        ReplyKeyPack ::= SEQUENCE {
1643           replyKey                [0] EncryptionKey,
1644                    -- Contains the session key used to encrypt the
1645                    -- enc-part field in the AS-REP.
1646           asChecksum              [1] Checksum,
1647                   -- Contains the checksum of the AS-REQ
1648                   -- corresponding to the containing AS-REP.
1649                   -- The checksum is performed over the type AS-REQ.
1650                   -- The protocol key [RFC3961] of the checksum is the
1651                   -- replyKey and the key usage number is 6.
1652                   -- If the replyKey's enctype is "newer" [RFC4120]
1653                   -- [RFC4121], the checksum is the required
1654                   -- checksum operation [RFC3961] for that enctype.
1655                   -- The client MUST verify this checksum upon receipt
1656                   -- of the AS-REP.
1657           ...
1658        }
1659
1660        TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
1661                    -- Each AlgorithmIdentifier specifies a set of
1662                    -- Diffie-Hellman domain parameters [IEEE1363].
1663                    -- This list is in decreasing preference order.
1664        END
1665
1666
1667
1668
1669
1670
1671 Tung & Zhu               Expires March 16, 2006                [Page 30]
1672 \f
1673 Internet-Draft                   PKINIT                   September 2005
1674
1675
1676 Appendix B.  Test Vectors
1677
1678    Function octetstring2key() is defined in Section 3.2.3.1.  This
1679    section describes a few sets of test vectors that would be useful for
1680    implementers of octetstring2key().
1681
1682
1683    Set 1
1684    =====
1685    Input octet string x is:
1686
1687      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1688      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1689      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1690      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1691      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1692      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1693      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1694      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1695      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1696      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1697      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1698      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1699      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1700      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1701      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1702      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1703
1704    Output of K-truncate() when the key size is 32 octets:
1705
1706      5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
1707      75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
1708
1709
1710    Set 2:
1711    =====
1712    Input octet string x is:
1713
1714      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1715      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1716      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1717      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1718      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1719      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1720      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1721      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1722
1723    Output of K-truncate() when the key size is 32 octets:
1724
1725
1726
1727 Tung & Zhu               Expires March 16, 2006                [Page 31]
1728 \f
1729 Internet-Draft                   PKINIT                   September 2005
1730
1731
1732      ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
1733      a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
1734
1735
1736    Set 3:
1737    ======
1738    Input octet string x is:
1739
1740      00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
1741      10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
1742      0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
1743      0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
1744      0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
1745      0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
1746      0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
1747      0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
1748
1749    Output of K-truncate() when the key size is 32 octets:
1750
1751      c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
1752      73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
1753
1754
1755    Set 4:
1756    =====
1757    Input octet string x is:
1758
1759      00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
1760      10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
1761      0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
1762      0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
1763      0d 0e 0f 10 00 01 02 03 04 05 06 07 08
1764
1765    Output of K-truncate() when the key size is 32 octets:
1766
1767      00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
1768      59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783 Tung & Zhu               Expires March 16, 2006                [Page 32]
1784 \f
1785 Internet-Draft                   PKINIT                   September 2005
1786
1787
1788 Authors' Addresses
1789
1790    Brian Tung
1791    USC Information Sciences Institute
1792    4676 Admiralty Way Suite 1001, Marina del Rey CA
1793    Marina del Rey, CA  90292
1794    US
1795
1796    Email: brian@isi.edu
1797
1798
1799    Larry Zhu
1800    Microsoft Corporation
1801    One Microsoft Way
1802    Redmond, WA  98052
1803    US
1804
1805    Email: lzhu@microsoft.com
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839 Tung & Zhu               Expires March 16, 2006                [Page 33]
1840 \f
1841 Internet-Draft                   PKINIT                   September 2005
1842
1843
1844 Intellectual Property Statement
1845
1846    The IETF takes no position regarding the validity or scope of any
1847    Intellectual Property Rights or other rights that might be claimed to
1848    pertain to the implementation or use of the technology described in
1849    this document or the extent to which any license under such rights
1850    might or might not be available; nor does it represent that it has
1851    made any independent effort to identify any such rights.  Information
1852    on the procedures with respect to rights in RFC documents can be
1853    found in BCP 78 and BCP 79.
1854
1855    Copies of IPR disclosures made to the IETF Secretariat and any
1856    assurances of licenses to be made available, or the result of an
1857    attempt made to obtain a general license or permission for the use of
1858    such proprietary rights by implementers or users of this
1859    specification can be obtained from the IETF on-line IPR repository at
1860    http://www.ietf.org/ipr.
1861
1862    The IETF invites any interested party to bring to its attention any
1863    copyrights, patents or patent applications, or other proprietary
1864    rights that may cover technology that may be required to implement
1865    this standard.  Please address the information to the IETF at
1866    ietf-ipr@ietf.org.
1867
1868
1869 Disclaimer of Validity
1870
1871    This document and the information contained herein are provided on an
1872    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1873    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1874    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1875    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1876    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1877    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1878
1879
1880 Copyright Statement
1881
1882    Copyright (C) The Internet Society (2005).  This document is subject
1883    to the rights, licenses and restrictions contained in BCP 78, and
1884    except as set forth therein, the authors retain all their rights.
1885
1886
1887 Acknowledgment
1888
1889    Funding for the RFC Editor function is currently provided by the
1890    Internet Society.
1891
1892
1893
1894
1895 Tung & Zhu               Expires March 16, 2006                [Page 34]
1896 \f
1897