doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-03.txt

   1
   2
   3 Network Working Group                               L. Hornquist Astrand
   4 Internet-Draft                                      Stockholm University
   5 Intended status: Standards Track                                  L. Zhu
   6 Expires: January 10, 2008                          Microsoft Corporation
   7                                                             July 9, 2007
   8
   9
  10                        PK-INIT algorithm agility
  11                 draft-ietf-krb-wg-pkinit-alg-agility-03
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on January 10, 2008.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The IETF Trust (2007).
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54 Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 1]
  55 \f
  56 Internet-Draft          PK-INIT algorithm agility              July 2007
  57
  58
  59 Abstract
  60
  61    The PK-INIT defined in RFC 4556 is examined and updated to remove
  62    protocol structures tied to specific cryptographic algorithms.  The
  63    affinity to SHA-1 as the checksum algorithm in the authentication
  64    request is analyzed.  The PK-INIT key derivation function is made
  65    negotiable, the digest algorithms for signing the pre-authentication
  66    data and the client's X.509 certificates are made discoverable.
  67
  68    These changes provide protection preemptively against vulnerabilities
  69    discovered in the future against any specific cryptographic
  70    algorithm, and allow incremental deployment of newer algorithms.
  71
  72
  73 Table of Contents
  74
  75    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  76    2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
  77    3.  paChecksum Agility . . . . . . . . . . . . . . . . . . . . . .  6
  78    4.  CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . .  7
  79    5.  X.509 Certificate Signer Algorithm Agility . . . . . . . . . .  8
  80    6.  KDF agility  . . . . . . . . . . . . . . . . . . . . . . . . .  9
  81    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
  82    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
  83    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
  84    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  85      10.1.  Normative References  . . . . . . . . . . . . . . . . . . 16
  86      10.2.  Informative References  . . . . . . . . . . . . . . . . . 17
  87    Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 18
  88    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
  89    Intellectual Property and Copyright Statements . . . . . . . . . . 21
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110 Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 2]
 111 \f
 112 Internet-Draft          PK-INIT algorithm agility              July 2007
 113
 114
 115 1.  Introduction
 116
 117    In August 2004, Xiaoyun Wang's research group reported MD4 [RFC1320]
 118    collisions generated using hand calculation [WANG04] alongside
 119    attacks on later hash function designs in the MD4, MD5 [RFC1321] and
 120    SHA [RFC4634] family.  Implementations based on Wang's algorithm can
 121    find collisions in real time.  These discoveries challenged the
 122    security for protocols relying on the collision resistance properties
 123    of these hashes, for example one can forge a digital signature when
 124    SHA-1 [RFC4634] is the digest algorithm.  A more far reaching side
 125    effect of these recent events, however, is that it is now generally
 126    considered flawed or distasteful at least if protocols are designed
 127    to use only specific algorithms.
 128
 129    The Internet Engineer Task Force (IETF) called for actions to update
 130    existing protocols to provide crypto algorithm agility in order to
 131    untie protocols with specific algorithms.  The idea is that if the
 132    protocol has crypto algorithm agility, and when a new vulnerability
 133    specific to an algorithm is discovered, this algorithm can be
 134    disabled via protocol negotiation quickly, thus we can avoid the wait
 135    for the multi-year standardization and implementation efforts to
 136    update the protocols.  In additon, crypto agility allows deployment
 137    of new crypto algorithms to be done incrementally, rather than
 138    requring a "flag day" on which the change must be deployed everywhere
 139    at the same time in order to maintain interoperability.
 140
 141    This document is to update PK-INIT [RFC4556] to provide crypto
 142    algorithm agility.  Several protocol structures used in the [RFC4556]
 143    protocol are either tied to SHA-1, or require the algorithms not
 144    negotiated but rather based on local policy.  The following concerns
 145    have been addressed:
 146
 147    o  The checksum algorithm in the authentication request is hardwired
 148       to use SHA-1 [RFC4634].
 149
 150    o  The acceptable digest algorithms for signing the authentication
 151       data are not discoverable.
 152
 153    o  The key derivation function in Section 3.2.3 of [RFC4556] is
 154       hardwired to use SHA-1.
 155
 156    o  The acceptable digest algorithms for signing the client X.509
 157       certificates are not discoverable.
 158
 159    To accomplish these, new key derivation functions (KDFs) identifiable
 160    by object identifiers are defined.  The PKINIT client provides a list
 161    of KDFs in the request and the KDC picks one in the response, thus a
 162    mutually-supported KDF is negotiated.
 163
 164
 165
 166 Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 3]
 167 \f
 168 Internet-Draft          PK-INIT algorithm agility              July 2007
 169
 170
 171    Furthermore, structures are defined to allow the client discover the
 172    Cryptographic Message Syntax (CMS) [RFC3852] digest algorithms
 173    supported by the KDC for signing the pre-authentication data and
 174    signing the client X.509 certificate.
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222 Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 4]
 223 \f
 224 Internet-Draft          PK-INIT algorithm agility              July 2007
 225
 226
 227 2.  Requirements Notation
 228
 229    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 230    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 231    document are to be interpreted as described in [RFC2119].
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278 Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 5]
 279 \f
 280 Internet-Draft          PK-INIT algorithm agility              July 2007
 281
 282
 283 3.  paChecksum Agility
 284
 285    The paChecksum defined in Section 3.2.1 of [RFC4556] provides a
 286    cryptographic binding between the client's pre-authentication data
 287    and the corresponding Kerberos request body.  This also prevents the
 288    KDC body from being tempered with.  SHA-1 is the only allowed
 289    checksum algorithm defined in [RFC4556].  This facility relies the
 290    collision resistance properties of the SHA-1 checksum [RFC4634].
 291
 292    When the reply key delivery mechanism is based on public key
 293    encryption as described in Section 3.2.3. of [RFC4556], the
 294    asChecksum in the KDC reply provides the binding between the pre-
 295    authentication and the ticket request and response messages, and
 296    integrity protection for the unauthenticated clear text in these
 297    messages.  However, if the reply key delivery mechanism is based on
 298    the Diffie-Hellman key agreement as described in Section 3.2.3.1 of
 299    [RFC4556], the security provided by using SHA-1 in the paChecksum is
 300    weak.  In this case, the new KDF selected by the KDC as described in
 301    Section 6 provides the cryptographic binding and integrity
 302    protection.
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334 Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 6]
 335 \f
 336 Internet-Draft          PK-INIT algorithm agility              July 2007
 337
 338
 339 4.  CMS Digest Algorithm Agility
 340
 341    When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
 342    as described In section 3.2.2 of [RFC4556], implementations
 343    comforming to this specification can OPTIONALLY send back a list of
 344    supported CMS types signifying the digest algorithms supported by the
 345    KDC, in the decreasing preference order.  This is accomplished by
 346    including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the
 347    error data.
 348
 349
 350
 351    TD-CMS-DIGEST-ALGORITHMS ::= INTEGER 111
 352
 353
 354    The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains
 355    the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded
 356    TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows:
 357
 358
 359
 360    TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
 361        AlgorithmIdentifier
 362            -- Contains the list of CMS algorithm [RFC3852]
 363            -- identifiers that identify the digest algorithms
 364            -- acceptable by the KDC for signing CMS data in
 365            -- the order of decreasing preference.
 366
 367
 368    The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy
 369    digest algorithms supported by the KDC.
 370
 371    This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS
 372    can facilitate trouble-shooting when none of the digest algorithms
 373    supported by the client is supported by the KDC.
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390 Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 7]
 391 \f
 392 Internet-Draft          PK-INIT algorithm agility              July 2007
 393
 394
 395 5.  X.509 Certificate Signer Algorithm Agility
 396
 397    When the client's X.509 certificate is rejected and the
 398    KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as
 399    described in section 3.2.2 of [RFC4556], conforming implementations
 400    can OPTIONALLY send a list of digest algorithms acceptable by the KDC
 401    for use by the CA in signing the client's X.509 certificate, in the
 402    decreasing preference order.  This is accomplished by including a
 403    TD_CERT_DIGEST_ALGORITHMS typed data element in the error data.  The
 404    corresponding data contains the ASN.1 DER encoding of the structure
 405    TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows:
 406
 407
 408    TD-CERT-DIGEST-ALGORITHMS ::= INTEGER 112
 409
 410    TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
 411            allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
 412                       -- Contains the list of CMS algorithm [RFC3852]
 413                       -- identifiers that identify the digest algorithms
 414                       -- that are used by the CA to sign the client's
 415                       -- X.509 certificate and acceptable by the KDC in
 416                       -- the process of validating the client's X.509
 417                       -- certificate, in the order of decreasing
 418                       -- preference.
 419            rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
 420                       -- This identifies the digest algorithm that was
 421                       -- used to sign the client's X.509 certificate and
 422                       -- has been rejected by the KDC in the process of
 423                       -- validating the client's X.509 certificate
 424                       -- [RFC3280].
 425            ...
 426    }
 427
 428
 429    The KDC fills in allowedAlgorithm field with the list of algorithm
 430    [RFC3852] identifiers that identify digest algorithms that are used
 431    by the CA to sign the client's X.509 certificate and acceptable by
 432    the KDC in the process of validating the client's X.509 certificate,
 433    in the order of decreasing preference.  The rejectedAlgorithm field
 434    identifies the signing algorithm for use in signing the client's
 435    X.509 certificate that has been rejected by the KDC in the process of
 436    validating the client's certificate [RFC3280].
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446 Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 8]
 447 \f
 448 Internet-Draft          PK-INIT algorithm agility              July 2007
 449
 450
 451 6.  KDF agility
 452
 453    Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines
 454    a Key Derivation Function (KDF) that derives a Kerberos protocol key
 455    based on the secret value generated by the Diffie-Hellman key
 456    exchange.  This KDF requires the use of SHA-1 [RFC4634].
 457
 458    New KDFs defined in this document based on [SP80056A] can be used in
 459    conjunction with any hash functions.  A new KDF is identified by an
 460    object identifier.  The following KDF object identifiers are defined:
 461
 462
 463
 464    id-pkinit-kdf OBJECT IDENTIFIER           ::= { id-pkinit 6 }
 465        -- PKINIT KDFs
 466    id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER   ::= { id-pkinit-kdf 1 }
 467        -- SP800 56A ASN.1 structured hash based KDF using SHA-1
 468    id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 }
 469        -- SP800 56A ASN.1 structured hash based KDF using SHA-256
 470    id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 }
 471        -- SP800 56A ASN.1 structured hash based KDF using SHA-512
 472
 473
 474    Where id-pkinit is defined in [RFC4556].  The id-pkinit-kdf-ah-sha1
 475    KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that
 476    uses SHA-1 [RFC4634] as the hash function.  Similarly id-pkinit-kdf-
 477    ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF
 478    using SHA-256 [RFC4634] and SHA-512 [RFC4634] respectively.  The
 479    common input parameters for these KDFs are provided as follows:
 480
 481    o  The secret value is the shared secret value generated by the
 482       Diffie-Hellman exchange.  The Diffie-Hellman shared value is first
 483       padded with leading zeros such that the size of the secret value
 484       in octets is the same as that of the modulus, then represented as
 485       a string of octets in big-endian order.
 486
 487    o  The key data length is K. K is the key-generation seed length in
 488       bits [RFC3961] for the Authentication Service (AS) reply key.  The
 489       enctype of the AS reply key is selected according to [RFC4120].
 490
 491    o  The algorithm identifier input parameter is the identifier of the
 492       respective KDF.  For example, this is id-pkinit-kdf-ah-sha1 if the
 493       KDF is the [SP80056A] ASN.1 structured HKDF using SHA-1 as the
 494       hash.
 495
 496    o  The initiator identifier is an OCTET STRING that contains the
 497       ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that
 498       identifies the client as specified in the AS-REQ [RFC4120] in the
 499
 500
 501
 502 Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 9]
 503 \f
 504 Internet-Draft          PK-INIT algorithm agility              July 2007
 505
 506
 507       request.
 508
 509    o  The recipient identifier is an OCTET STRING that contains the
 510       ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that
 511       identifies the TGS as specified in the AS-REQ [RFC4120] in the
 512       request.
 513
 514    o  The supplemental private information is absent (not used).
 515
 516    o  The supplemental public information is an OCTET STRING that
 517       contains the ASN.1 DER encoding of the structure PkinitSuppPubInfo
 518       as defined later in this section.
 519
 520    o  The hash length is 128 for id-pkinit-kdf-ah-sha1, 256 for id-
 521       pkinit-kdf-ah-sha256, and 512 for id-pkinit-kdf-ah-sha512.
 522
 523    o  The maximum hash input length is 2^64 in bits.
 524
 525    The structure PkinitSuppPubInfo is defined as follows:
 526
 527
 528    PkinitSuppPubInfo ::= SEQUENCE {
 529           enctype           [0] Int32,
 530               -- The enctype of the AS reply key.
 531           as-REQ            [1] OCTET STRING,
 532               -- This contains the AS-REQ in the request.
 533           pk-as-rep         [2] OCTET STRING,
 534               -- Contains the DER encoding of the type
 535               -- PA-PK-AS-REP [RFC4556] in the KDC reply.
 536           ticket            [3] Ticket,
 537               -- This is the ticket in the KDC reply.
 538           ...
 539    }
 540
 541
 542    The PkinitSuppPubInfo structure contains mutually-known public
 543    information specific to the authentication exchange.  The enctype
 544    field is the enctype of the AS reply key as selected according to
 545    [RFC4120].  The as-REQ field contains the DER encoding of the type
 546    AS-REQ [RFC4120] in the request sent from the client to the KDC.
 547    Note that the as-REQ field does not include the wrapping 4 octet
 548    length field when TCP is used.  The pk-as-rep field contains the DER
 549    encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply.  The
 550    ticket field is filled with the ticket in the KDC reply.  The
 551    PkinitSuppPubInfo provides a cryptographic bindings between the pre-
 552    authentication data and the corresponding ticket request and
 553    response, thus addressing the concerns described in Section 3.
 554
 555
 556
 557
 558 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 10]
 559 \f
 560 Internet-Draft          PK-INIT algorithm agility              July 2007
 561
 562
 563    The above ASN.1 structured [SP80056A] HKDF produces a bit string of
 564    length K in bits as the keying material, and then the AS reply key is
 565    the output of random-to-key() [RFC3961] using that returned keying
 566    material as the input.
 567
 568    The KDF is negotiated between the client and the KDC.  The client
 569    sends an unordered set of supported KDFs in the request, and the KDC
 570    picks one from the set in the reply.
 571
 572    To acomplish this, the AuthPack structure in [RFC4556] is extended as
 573    follows:
 574
 575
 576    AuthPack ::= SEQUENCE {
 577           pkAuthenticator   [0] PKAuthenticator,
 578           clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
 579           supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
 580                    OPTIONAL,
 581           clientDHNonce     [3] DHNonce OPTIONAL,
 582           ...,
 583           supportedKDFs     [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
 584               -- Contains an unordered set of KDFs supported by the
 585               -- client.
 586           ...
 587    }
 588
 589    KDFAlgorithmId ::= SEQUENCE {
 590           kdf-id            [0] OBJECT IDENTIFIER,
 591               -- The object identifier of the KDF
 592           ...
 593    }
 594
 595
 596    The new field supportedKDFs contains an unordered set of KDFs
 597    supported by the client.
 598
 599    The KDFAlgorithmId structure contains an object identifier that
 600    identifies a KDF.  The algorithm of the KDF and its parameters are
 601    defined by the corresponding specification of that KDF.
 602
 603    The DHRepInfo structure in [RFC4556] is extended as follows:
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 11]
 615 \f
 616 Internet-Draft          PK-INIT algorithm agility              July 2007
 617
 618
 619    DHRepInfo ::= SEQUENCE {
 620            dhSignedData         [0] IMPLICIT OCTET STRING,
 621            serverDHNonce        [1] DHNonce OPTIONAL,
 622            ...,
 623            kdf                  [2] KDFAlgorithmId OPTIONAL,
 624                -- The KDF picked by the KDC.
 625            ...
 626    }
 627
 628
 629    The new field kdf in the extended DHRepInfo structure identifies the
 630    KDF picked by the KDC.  This kdf field MUST be filled by the
 631    comforming KDC if the supportedKDFs field is present in the request,
 632    and it MUST be one of the KDFs supported by the client as indicated
 633    in the request.  Which KDF is chosen is a matter of the local policy
 634    on the KDC.
 635
 636    If the supportedKDFs field is not present in the request, the kdf
 637    field in the reply MUST be absent.
 638
 639    If the client fills the supportedKDFs field in the request, but the
 640    kdf field in the reply is not present, the client can deduce that the
 641    KDC is not updated to conform with this specification.  In that case,
 642    it is a matter of local policy on the client whether to reject the
 643    reply when the kdf field is absent in the reply.
 644
 645    Implementations comforming to this specification MUST support id-
 646    pkinit-kdf-ah-sha256.
 647
 648    If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF
 649    (82).
 650
 651    PKINIT introduces the following new error code:
 652
 653    o  KDC_ERR_NO_ACCEPTABLE_KDF 82
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 12]
 671 \f
 672 Internet-Draft          PK-INIT algorithm agility              July 2007
 673
 674
 675 7.  Security Considerations
 676
 677    This document describes negotiation of checksum types, key derivation
 678    functions and other cryptographic functions.  If negotiation is done
 679    unauthenticated, care MUST be taken to accept only acceptable values.
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 13]
 727 \f
 728 Internet-Draft          PK-INIT algorithm agility              July 2007
 729
 730
 731 8.  Acknowledgements
 732
 733    Jeffery Hutzelman and Shawn Emery reviewed the document and provided
 734    suggestions for improvements.
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 14]
 783 \f
 784 Internet-Draft          PK-INIT algorithm agility              July 2007
 785
 786
 787 9.  IANA Considerations
 788
 789    No IANA considerations.
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 15]
 839 \f
 840 Internet-Draft          PK-INIT algorithm agility              July 2007
 841
 842
 843 10.  References
 844
 845 10.1.  Normative References
 846
 847    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 848               Requirement Levels", BCP 14, RFC 2119, March 1997.
 849
 850    [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
 851               X.509 Public Key Infrastructure Certificate and
 852               Certificate Revocation List (CRL) Profile", RFC 3280,
 853               April 2002.
 854
 855    [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
 856               Public Keys Used For Exchanging Symmetric Keys", BCP 86,
 857               RFC 3766, April 2004.
 858
 859    [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
 860               RFC 3852, July 2004.
 861
 862    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
 863               Kerberos 5", RFC 3961, February 2005.
 864
 865    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 866               Kerberos Network Authentication Service (V5)", RFC 4120,
 867               July 2005.
 868
 869    [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
 870               Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
 871
 872    [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
 873               (SHA and HMAC-SHA)", July 2006.
 874
 875    [SP80056A]
 876               Barker, E., Don, D., and M. Smid, "Recommendation for
 877               Pair-Wise Key Establishment Schemes Using Discrete
 878               Logarithm Cryptography", March 2006.
 879
 880    [X680]     ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
 881               1:2002, Information technology - Abstract Syntax Notation
 882               One (ASN.1): Specification of basic notation".
 883
 884    [X690]     ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-
 885               1:2002, Information technology - ASN.1 encoding Rules:
 886               Specification of Basic Encoding Rules (BER), Canonical
 887               Encoding Rules (CER) and Distinguished Encoding Rules
 888               (DER)".
 889
 890
 891
 892
 893
 894 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 16]
 895 \f
 896 Internet-Draft          PK-INIT algorithm agility              July 2007
 897
 898
 899 10.2.  Informative References
 900
 901    [RFC1320]  Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
 902               April 1992.
 903
 904    [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
 905               April 1992.
 906
 907    [WANG04]   Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu,
 908               "Cryptanalysis of Hash functions MD4 and RIPEMD",
 909               August 2004.
 910
 911    [X9.42]    ANSI, "Public Key Cryptography for the Financial Services
 912               Industry: Agreement of Symmetric Keys Using Discrete
 913               Logarithm Cryptography", 2003.
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 17]
 951 \f
 952 Internet-Draft          PK-INIT algorithm agility              July 2007
 953
 954
 955 Appendix A.  PKINIT ASN.1 Module
 956
 957
 958
 959    KerberosV5-PK-INIT-Agility-SPEC {
 960           iso(1) identified-organization(3) dod(6) internet(1)
 961           security(5) kerberosV5(2) modules(4) pkinit(5) agility (1)
 962    } DEFINITIONS EXPLICIT TAGS ::= BEGIN
 963
 964    IMPORTS
 965       AlgorithmIdentifier, SubjectPublicKeyInfo
 966           FROM PKIX1Explicit88 { iso (1)
 967             identified-organization (3) dod (6) internet (1)
 968             security (5) mechanisms (5) pkix (7) id-mod (0)
 969             id-pkix1-explicit (18) }
 970             -- As defined in RFC 3280.
 971
 972       Ticket, Int32, Realm, EncryptionKey, Checksum
 973           FROM KerberosV5Spec2 { iso(1) identified-organization(3)
 974             dod(6) internet(1) security(5) kerberosV5(2)
 975             modules(4) krb5spec2(2) }
 976             -- as defined in RFC 4120.
 977
 978       PKAuthenticator, DHNonce
 979           FROM KerberosV5-PK-INIT-SPEC {
 980             iso(1) identified-organization(3) dod(6) internet(1)
 981             security(5) kerberosV5(2) modules(4) pkinit(5) };
 982             -- as defined in RFC 4556.
 983
 984    TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
 985        AlgorithmIdentifier
 986            -- Contains the list of CMS algorithm [RFC3852]
 987            -- identifiers that identify the digest algorithms
 988            -- acceptable by the KDC for signing CMS data in
 989            -- the order of decreasing preference.
 990
 991    TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
 992           allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
 993               -- Contains the list of CMS algorithm [RFC3852]
 994               -- identifiers that identify the digest algorithms
 995               -- that are used by the CA to sign the client's
 996               -- X.509 certificate and acceptable by the KDC in
 997               -- the process of validating the client's X.509
 998               -- certificate, in the order of decreasing
 999               -- preference.
1000           rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
1001               -- This identifies the digest algorithm that was
1002               -- used to sign the client's X.509 certificate and
1003
1004
1005
1006 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 18]
1007 \f
1008 Internet-Draft          PK-INIT algorithm agility              July 2007
1009
1010
1011               -- has been rejected by the KDC in the process of
1012               -- validating the client's X.509 certificate
1013               -- [RFC3280].
1014           ...
1015    }
1016
1017    PkinitSuppPubInfo ::= SEQUENCE {
1018           enctype           [0] Int32,
1019               -- The enctype of the AS reply key.
1020           as-REQ            [1] OCTET STRING,
1021               -- This contains the AS-REQ in the request.
1022           pk-as-rep         [2] OCTET STRING,
1023               -- Contains the DER encoding of the type
1024               -- PA-PK-AS-REP [RFC4556] in the KDC reply.
1025           ticket            [3] Ticket,
1026               -- This is the ticket in the KDC reply.
1027           ...
1028    }
1029
1030    AuthPack ::= SEQUENCE {
1031           pkAuthenticator   [0] PKAuthenticator,
1032           clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1033           supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1034                    OPTIONAL,
1035           clientDHNonce     [3] DHNonce OPTIONAL,
1036           ...,
1037           supportedKDFs     [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
1038               -- Contains an unordered set of KDFs supported by the
1039               -- client.
1040           ...
1041    }
1042
1043    KDFAlgorithmId ::= SEQUENCE {
1044           kdf-id            [0] OBJECT IDENTIFIER,
1045               -- The object identifier of the KDF
1046           ...
1047    }
1048
1049    DHRepInfo ::= SEQUENCE {
1050           dhSignedData      [0] IMPLICIT OCTET STRING,
1051           serverDHNonce     [1] DHNonce OPTIONAL,
1052           ...,
1053           kdf               [2] KDFAlgorithmId OPTIONAL,
1054               -- The KDF picked by the KDC.
1055           ...
1056    }
1057    END
1058
1059
1060
1061
1062 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 19]
1063 \f
1064 Internet-Draft          PK-INIT algorithm agility              July 2007
1065
1066
1067 Authors' Addresses
1068
1069    Love Hornquist Astrand
1070    Stockholm University
1071    SE-106 91 Stockholm
1072    Sweden
1073
1074    Email: lha@it.su.se
1075
1076
1077    Larry Zhu
1078    Microsoft Corporation
1079    One Microsoft Way
1080    Redmond, WA  98052
1081    US
1082
1083    Email: lzhu@microsoft.com
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 20]
1119 \f
1120 Internet-Draft          PK-INIT algorithm agility              July 2007
1121
1122
1123 Full Copyright Statement
1124
1125    Copyright (C) The IETF Trust (2007).
1126
1127    This document is subject to the rights, licenses and restrictions
1128    contained in BCP 78, and except as set forth therein, the authors
1129    retain all their rights.
1130
1131    This document and the information contained herein are provided on an
1132    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1133    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1134    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1135    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1136    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1137    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1138
1139
1140 Intellectual Property
1141
1142    The IETF takes no position regarding the validity or scope of any
1143    Intellectual Property Rights or other rights that might be claimed to
1144    pertain to the implementation or use of the technology described in
1145    this document or the extent to which any license under such rights
1146    might or might not be available; nor does it represent that it has
1147    made any independent effort to identify any such rights.  Information
1148    on the procedures with respect to rights in RFC documents can be
1149    found in BCP 78 and BCP 79.
1150
1151    Copies of IPR disclosures made to the IETF Secretariat and any
1152    assurances of licenses to be made available, or the result of an
1153    attempt made to obtain a general license or permission for the use of
1154    such proprietary rights by implementers or users of this
1155    specification can be obtained from the IETF on-line IPR repository at
1156    http://www.ietf.org/ipr.
1157
1158    The IETF invites any interested party to bring to its attention any
1159    copyrights, patents or patent applications, or other proprietary
1160    rights that may cover technology that may be required to implement
1161    this standard.  Please address the information to the IETF at
1162    ietf-ipr@ietf.org.
1163
1164
1165 Acknowledgment
1166
1167    Funding for the RFC Editor function is provided by the IETF
1168    Administrative Support Activity (IASA).
1169
1170
1171
1172
1173
1174 Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 21]
1175 \f