Subject: PKINIT-33 and diffs with -32

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 18:16:53 -0800

205,212c205,212
<    [RFC3280] is popular for facilitating non-repudiation and perfect
<    secrecy.  An established Public Key Infrastructure (PKI) provides
key
<    management and key distribution mechanisms that can be used to
<    establish authentication and secure communication.  Adding
public-key
<    cryptography to Kerberos provides a nice congruence to public-key
<    protocols, obviates the human users' burden to manage strong
<    passwords, and allows Kerberized applications to take advantage of
<    existing key services and identity management.
---
>    [RFC3280] is popular for facilitating data origin authentication
and
>    perfect secrecy.  An established Public Key Infrastructure (PKI)
>    provides key management and key distribution mechanisms that can be
>    used to establish authentication and secure communication.  Adding
>    public-key cryptography to Kerberos provides a nice congruence to
>    public-key protocols, obviates the human users' burden to manage
>    strong passwords, and allows Kerberized applications to take
>    advantage of existing key services and identity management.

322,326c322,326
<    In addition, implementations of this specification MUST be capable
of
<    processing the Extended Key Usage (EKU) extension and the
id-pkinit-
<    san (as defined in Section 3.2.2) otherName of the Subject
<    Alternative Name (SAN) extension in X.509 certificates [RFC3280],
if
<    present.
---
>    o  Algorithms identified in the contentEncryptionAlgorithm field of
>       the type EncryptedContentInfo [RFC3852] for encrypting the
>       temporary key in the encryptedKey field of the type
>       KeyTransRecipientInfo [RFC3852] with a public key, as described
in
>       Section 3.2.3.2: rsaEncryption [RFC3447] [RFC3279].

328c328,331
< 3.1.2.  Defined Message and Encryption Types
---
>    o  Algorithms identified in the contentEncryptionAlgorithm field of
>       the type EncryptedContentInfo [RFC3852] for encrypting the AS
>       reply key with the temporary key contained in the encryptedKey
>       field of the type KeyTransRecipientInfo [RFC3852], as described
in
330d332
<    PKINIT makes use of the following new pre-authentication types:

339a340,351
>       Section 3.2.3.2: des-ede3-cbc (three-key 3DES, CBC mode)
>       [RFC3370].
> 
>    In addition, implementations of this specification MUST be capable
of
>    processing the Extended Key Usage (EKU) extension and the
id-pkinit-
>    san (as defined in Section 3.2.2) otherName of the Subject
>    Alternative Name (SAN) extension in X.509 certificates [RFC3280].
> 
> 3.1.2.  Defined Message and Encryption Types
> 
>    PKINIT makes use of the following new pre-authentication types:
> 
376d387
<    corresponding specifications.
378,382d388
<    Interoperability note: Some implementations may not be able to
decode
<    wrapped CMS objects encoded with BER; specifically, they may not be
<    able to decode indefinite length encodings.  To maximize
<    interoperability, implementers SHOULD encode CMS objects used in
<    PKINIT with DER.
384d389
< 3.1.3.  Algorithm Identifiers
386,391c391
<    PKINIT does not define, but does make use of, the following
algorithm
<    identifiers.
< 
< 
< 

396,397c396
<    PKINIT uses the following algorithm identifier(s) for Modular
<    Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
---
>    corresponding specifications.
399c398,402
<        dhpublicnumber (as described in [RFC3279])
---
>    Interoperability note: Some implementations may not be able to
decode
>    wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects
encoded
>    with BER; specifically, they may not be able to decode indefinite
>    length encodings.  To maximize interoperability, implementers
SHOULD
>    encode CMS objects used in PKINIT with DER.
401,402c404
<    PKINIT uses the following signature algorithm identifiers as
defined
<    in [RFC3279]:
---
> 3.1.3.  Kerberos Encryption Types for CMS Algorithm Identifiers
404,406c406,411
<        sha-1WithRSAEncryption (RSA with SHA1)
<        md5WithRSAEncryption   (RSA with MD5)
<        id-dsa-with-sha1       (DSA with SHA1)
---
>    For historical reasons, PKINIT defines the following Kerberos
>    encryption types [RFC4120], for use in the etype field of the
AS-REQ
>    [RFC4120] message to indicate acceptance of the corresponding
>    algorithms (including public encryption algorithms, bulk encryption
>    agorithms, and signature algorithms) that can used by Cryptographic
>    Message Syntax (CMS) [RFC3852] messages in the reply:
408,425d412
<    PKINIT uses the following encryption algorithm identifiers as
defined
<    in [RFC3447] for encrypting the temporary key with a public key:
< 
<        rsaEncryption
<        id-RSAES-OAEP
< 
<    PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
<    for encrypting the AS reply key with the temporary key:
< 
<        des-ede3-cbc (three-key 3DES, CBC mode, as defined in
[RFC3370])
<        rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
<        id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
< 
<    PKINIT defines the following encryption types, for use in the etype
<    field of the AS-REQ [RFC4120] message to indicate acceptance of the
<    corresponding algorithms that can used by Cryptographic Message
<    Syntax (CMS) [RFC3852] messages in the reply:
< 
427c414,415
<           -- Indicates that the client supports id-dsa-with-sha1.
---
>           -- Indicates that the client supports id-dsa-with-sha1
>           -- [RFC3279].
429c417,418
<           -- Indicates that the client supports md5WithRSAEncryption.
---
>           -- Indicates that the client supports md5WithRSAEncryption
>           -- [RFC3279].
431c420,421
<           -- Indicates that the client supports
sha-1WithRSAEncryption.
---
>           -- Indicates that the client supports sha-1WithRSAEncryption
>           -- [RFC3279].
433c423
<           -- Indicates that the client supports rc2-cbc.
---
>           -- Indicates that the client supports rc2-cbc [RFC3370].
435c425,426
<           -- Indicates that the client supports rsaEncryption.
---
>           -- Indicates that the client supports rsaEncryption
>           -- [RFC3447] [RFC3279].
437c428,429
<           -- Indicates that the client supports id-RSAES-OAEP.
---
>           -- Indicates that the client supports id-RSAES-OAEP
>           -- [RFC3447] [RFC3279].
439c431
<           -- Indicates that the client supports des-ede3-cbc.
---
>           -- Indicates that the client supports des-ede3-cbc
[RFC3370].
440a433,437
>    Per [RFC4120], these encryption types are sent in the decreasing
>    preference order of the client, and there is no significance in the
>    relative order between any two of different types of algorithms:
>    public key encryption algorithms, bulk encryption algorithms, and
>    signature algorithms.
441a439,442
>    In the etype field of the AS-REQ, the client SHOULD send the
kerberos
>    encryption type corresponding to the CMS algorithm idenitifer if
that
>    algorithm identifier is assigned with a kerberos encryption type in
>    the encryption type list above.

548,549c548,550
<                    -- List of CMS encryption types supported by the
<                    -- client in order of (decreasing) preference.
---
>                    -- List of CMS encryption, bulk encryption,
>                    -- or signature algorithm identifiers supported by
>                    -- the client in order of (decreasing) preference.
555d555
<        }
559c559
563a564,565
>        }
610,611d611
<        encryption types supported by the client in order of
(decreasing)
<        preference.  The clientDHNonce field is described later in this
615c615

620c620,632
<        section.
---
>        algorithm identifiers (for encryption algorithms, bulk
encryption
>        algorithms and signature algorithms) that are supported by the
>        client in order of (decreasing) preference, and can be used to
>        identify a signature agorithm or a public key encryption
>        algorithm in the keyEncryptionAlgorithm field of the type
>        KeyTransRecipientInfo or a bulk encryption algorithm in the
>        contentEncryptionAlgorithm field of the type
EncryptedContentInfo
>        [RFC3852] when encrypting the AS reply key as described in
>        Section 3.2.3.2.  However, there is no significance in the
>        relative order between any two of different types of
algorithms:
>        public key encryption algorithms, bulk encryption algorithms
and
>        signature algorithms.  The clientDHNonce field is described
later
>        in this section.

978a993,997
>    Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
>    data does permit empty SEQUENCEs to be encoded.  Such empty
sequences
>    may only be used if the KDC itself vouches for the user's
>    certificate.
> 
1382,1386d1424
<    Implementation note: CAs issuing KDC certificates SHOULD place all
<    "short" and "fully-qualified" Kerberos realm names of the KDC (one
<    per GeneralName [RFC3280]) into the KDC certificate to allow
maximum
<    flexibility.
< 

1443a1482,1493
>    The security of cryptographic algorithms is dependent on generating
>    secret quantities [RFC4086].  The number of truly random bits is
>    extremely important to determining the attack resistance strength
of
>    the cryptosystem, for example, the secret Diffie-Hellman exponents
>    must be chosen based on n truly random bits (where n is the system
>    security requirement).  The security of the overall system is
>    significantly weakened by using insufficient random inputs: a
>    sophisticated attacker may find it easier to reproduce the
>    environment that produced the secret quantities and to search the
>    resulting small set of possibilities than to locate the quantities
in
>    the whole of the potential number space.
> 
1504,1506c1553,1556
<    policies may allow the use of relatively weak public keys.  Using
<    such keys to wrap data encrypted under stronger conventional
<    cryptosystems may be inappropriate.
---
>    policies may allow the use of relatively weak public keys.  When
>    using such weak asymmetric keys to protect/exchange stronger
>    symmetric Keys, the attack resistant strength of the overall system
>    is no better than that of these weak keys [RFC3766].
1507a1558,1560
>    PKINIT requires keys for symmetric cryptosystems to be generated.
>    Some such systems contain "weak" keys.  For recommendations
regarding
>    these weak keys, see [RFC4120].
1508a1562,1563
>    PKINIT allows the use of the same RSA key pair for encryption and
>    signing when doing RSA encryption based key delivery.  This is not
1511c1566,1567
< Zhu & Tung                Expires July 15, 2006                [Page
27]
---
> 
> Zhu & Tung                Expires July 27, 2006                [Page
28]
1516,1521d1571
<    PKINIT requires keys for symmetric cryptosystems to be generated.
<    Some such systems contain "weak" keys.  For recommendations
regarding
<    these weak keys, see [RFC4120].
< 
<    PKINIT allows the use of the same RSA key pair for encryption and
<    signing when doing RSA encryption based key delivery.  This is not
1542,1545d1591
<    The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
<    permit empty SEQUENCEs to be encoded.  Such empty sequences may
only
<    be used if the KDC itself vouches for the user's certificate.
< 
11699a1736,1742
>               April 1999.
> 
>    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
>               Version 5 Generic Security Service Application Program
>               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
>               July 2005.
> 
1728a1772,1775
>        id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
>        id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
>        id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
>        id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
1731c1778,1779
< Zhu & Tung                Expires July 15, 2006                [Page
31]
---
> 
> Zhu & Tung                Expires July 27, 2006                [Page
32]
1736,1739d1783
<        id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
<        id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
<        id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
<        id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
1783a1828
>        }
1784a1830
>        DHNonce ::= OCTET STRING
1787c1833,1835
< 
<        DHNonce ::= OCTET STRING
< 
1839c1883,1887
<                    -- List of CMS encryption types supported by the
---
>                    -- List of CMS encryption, bulk encryption,
>                    -- or signature algorithm identifiers supported by
>                    -- the client in order of (decreasing) preference.
>           clientDHNonce           [3] DHNonce OPTIONAL,