Subject: PKINIT -29 changes

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 17 Oct 2005 02:13:45 -0700

Here is the output of the following command

diff draft-ietf-cat-kerberos-pk-init-28.txt
draft-ietf-cat-kerberos-pk-init-29.txt | clip

I filtered out the trivial date and revision changes (from -28 to -29)
and I am going to explain all the changes:

================================

I could not understand what rsaEncryption-EnvOID actually means by
reading
-28 alone, so the following editorial changes were meant to make that
clear:

270,273c270,273
<    PKINIT defines the following encryption types, for use in the
AS-REQ
<    message to indicate acceptance of the corresponding algorithms that
<    can used by Cryptographic Message Syntax (CMS) [RFC3852] messages
in
<    the reply:
---
>    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:
284a285
>           -- Indicates that the client supports dsaWithSHA1
285a287
>           -- Indicates that the client supports md5WithRSAEncryption
286a289
>           -- Indicates that the client supports sha1WithRSAEncryption
288,289c291,297
<        rsaEncryption-EnvOID   (PKCS1 v1.5)          13
<        rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
---
>           -- Indicates that the client supports rc2CBC
>        rsaEncryption-EnvOID                         13
>           -- Indicates that the client supports
>           --  rsaEncryption (PKCS1 v2.1)
>        id-RSAES-OAEP-EnvOID                         14
>           -- Indicates that the client supports
>           -- id-RSAES-OAEP (PKCS1 v2.1)
290a299
>           -- Indicates that the client supports des-ede3-cbc
323a333,339
327,328c343,344
<        rsaEncryption          (PKCS1 v1.5)
<        id-RSAES-OAEP          (PKCS1 v2.0)
---
>        rsaEncryption          (PKCS1 v2.1)
>        id-RSAES-OAEP          (PKCS1 v2.1)

The following text was moved around to make the context clear. These are
editorial changes.

< 
< 
768,772c778,779
<    The content of the AS-REP is otherwise unchanged from [RFC4120].
The
<    KDC encrypts the reply as usual, but not with the client's
long-term
<    key.  Instead, it encrypts it with either a shared key derived from
a
<    Diffie-Hellman exchange, or a generated encryption key.  The
contents
<    of the PA-PK-AS-REP indicate which key delivery method is used:
---
>    A pre-authentication data element, whose padata-type is
PA_PK_AS_REP
>    and whose padata-value contains the DER encoding of the type PA-PK-
>    AS-REP (defined below), is included in the AS-REP [RFC4120].
> 

>        }
836a854,858
>    The content of the AS-REP is otherwise unchanged from [RFC4120].
The
>    KDC encrypts the reply as usual, but not with the client's
long-term
>    key.  Instead, it encrypts it with either a shared key derived from
a
>    Diffie-Hellman exchange, or a generated encryption key.  The
contents
>    of the PA-PK-AS-REP indicate which key delivery method is used.
837a860,864
>    In addition, the life time of the TGT returned by the KDC MUST NOT
>    exceed the life time of the client's public key (the TGT's
lifetime,
>    however, can be shorter than that of the client's public key, and
the
>    lifetime of the client's public key is typically specified in the
>    validity field of X.509 certificates [RFC3280]).

The following corrected an incorrect OID

797c805
<                    -- (1.2.840.113549.1.7.3) and the eContent field
---
>                    -- (1.3.6.1.5.2.3.3) and the eContent field
827a836,843

The following editorial change corrected a typo:

1052c1078
<    If the public key encrytion method is used, the client MUST verify
---
>    If the public key encryption method is used, the client MUST verify

The following was added into the security consideration section:
1154a1182,1188
>    Kerberos error messages are not integrity protected, as a result,
the
>    domain parameters sent by the KDC as TD-DH-PARAMETERS can be
tampered
>    with by an attacker so that the set of domain parameters selected
>    could be either weaker or not mutually preferred.  Local policy can
>    configure sets of domain parameters acceptable locally, or disallow
>    the negotiation of DH domain parameters.
> 

The following changes were made in the acknowledgement section, to
reflect the contributes from various sources:

< 
1253c1280
<    draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
---
>    draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
1256,1257c1283
<    Jaganathan, Chaskiel M Grundman, Stefan Santesson, Andre Scedrov
and
<    Aaron D. Jaggard.
---
>    Jaganathan, and Chaskiel M Grundman.
1258a1285,1295
> 
> 
>    Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
>    Chris Walstad discovered a binding issue between the AS-REQ and AS-
>    REP in draft -27, the asChecksum field was added as the result.
> 
1284,1291d1320

A new appendix was added to describe a way how to validate KDC
certificates.
I will bring this up separately via email.

1773a1813
> Appendix C.  How to Securely Interoperate with Windows Vista
1774a1815,1817
>    Due to various constraints, CAs shipped with Windows Vista do not
>    automatically issue KDC certificates with id-pksan SAN.  This
section
>    describes how to validate these KDC certificates.
1775a1819,1827
>    o  All PKINIT clients MUST verify that the issuer of the KDC
>       certificate is authorized to issue KDC certificates for the
target
>       realm.  To accomplish this, for domain-joined machines, Windows
>       Vista PKINIT clients verify that the issuer of the KDC
certificate
>       is present in the "NTAuth" system registry store (the NTAuth
store
>       is managed via the group policy mechansim for domain joined
>       machines); For un-joined machines, Windows Vista PKINIT clients
>       verify that the KDC certificate is path-validated to a trust
>       anchor on the smartcard device itself.
1776a1829,1839
>    o  All PKINIT clients MUST verify that the KDC certificate is
>       intended for the KDC of the target realm.  KDC certificates
issued
>       by Windows Vista CAs have the dNSName SAN containing only the
>       domain name of the KDC and the intended purpose of these KDC
>       certificates are restricted by the presence of the following two
>       EKUs: id-pkkdcekuoid EKU and id-kp-serverAuth [RFC3280].  Note
>       that all Microsoft Kerberos realm names are domain style realm
>       names and they are strictly in upper case.  PKINIT clients can
>       verify these KDC certificates as follows: the target realm name
>       must match with the value of the dNSName SAN in the KDC
>       certificate and the id-pkkdcekuoid EKU must be present.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 17 Oct 2005 02:54:05 -0700

Attached is PKINIT-29. Hopefully this makes the diff output below easier
to read.

PKINIT-29 has NOT been submitted.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Liqiang(Larry)
Zhu
Sent: Monday, October 17, 2005 2:14 AM
To: [email-masked]
Subject: PKINIT -29 changes

270,273c270,273
284a285
285a287
286a289
288,289c291,297
290a299
323a333,339
327,328c343,344

< 
< 
768,772c778,779
PA_PK_AS_REP

836a854,858
The
long-term
a
contents
837a860,864
lifetime,
the

797c805
827a836,843

1052c1078

The following was added into the security consideration section:
1154a1182,1188
the
tampered

The following changes were made in the acknowledgement section, to
reflect the contributions from various sources:

< 
1253c1280
1256,1257c1283
1258a1285,1295
1284,1291d1320

1773a1813
> Appendix C.  How to Securely Interoperate with Windows Vista PKINIT
             Implementations
1774a1815,1817
section
1775a1819,1827
target
certificate
store
1776a1829,1839
issued
>       certificates is restricted by the presence of the following two