Subject: RE: pk-init22 part 1

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 26 Jan 2005 02:45:19 -0800

> L21.11 I think the client MUST NOT send the CMS Kerberos encryption
>    types if it only send the new TDB pa-type number but only use
>    the new supportedCMSTypes. 

I failed to see how the "MUST NOT" is justified.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Love
Sent: Wednesday, January 05, 2005 6:31 AM
To: [email-masked]
Subject: pk-init22 part 1

Let start off with old stuff.

Old Comments

----

>           caName                  [1] Name,
[..]
>      TrustedCertifiers ::= SEQUENCE OF Name
 
Name isn't wrapped, I can't see any comments on this on the mailing
list, this is an old issue:

L21.1 Why isn't Name in TrustedCA/TrustedCertifiers wrapped with OCTET
STRING.
   Same goes for CertificateIndex.

Name is a X509/X500 type, should that really be used in PK-INIT ?
Compare with the change that have been done to IssuerAndSerialNumber
(WrapIssuerAndSerial).

------ 

| [2] R. Housley. Cryptographic Message Syntax. April 1999.  Request For

| Comments 2630.

L21.12 RFC2630 is obsoleted by RFC3369, RFC3370.

| KDC-REQ-BODY to indicate which CMS [2] algorithms it supports.

L21.13 RFC3370 specifies the algorithms CMS uses, also RFC3565 refernced
   since that is the spec for use of the AES Encryption Algorithm in
CMS.
   So given this, the [2] needs to split in two, CMS as protocol and CMS
   algorithms.

Specificly these must be changed:

-   KDC-REQ-BODY to indicate which CMS [RFC2630] algorithms it supports.
+   KDC-REQ-BODY to indicate which CMS [RFC3370, RFC3565] algorithms
+   it supports.

-   structures must be encoded according to the rules specified in
-   Kerberos [CLAR] or CMS [RFC2630] as appropriate.
+   structures must be encoded according to the rules specified in
+   Kerberos [CLAR] or CMS [RFC3369] as appropriate.

+   PKINIT uses the following algorithm identifiers [RFC2630] for
+   encrypting the reply key with the temporary key:
-   PKINIT uses the following algorithm identifiers [RFC3370, RFC3565]
for
-   encrypting the reply key with the temporary key:

Please update the Normative References section. Add RFC3369, RFC3370,
and RFC3565, remove RFC2630.

-----

L21.11 I think the client MUST NOT send the CMS kerberos encryption
    types if it only send the new TDB pa-type number but only use
    the new supportedCMSTypes.

-   The above encryption types are used by the client only within the
-   KDC-REQ-BODY to indicate which CMS [RFC2630] algorithms it supports.
-   Their use within Kerberos EncryptedData structures is not specified
-   by this document.

+   The above encryption types are used by the client only within the
+   KDC-REQ-BODY to indicate which CMS [RFC2630] algorithms it supports.
+   Their use within Kerberos EncryptedData structures is not specified
+   by this document. The client MUST only send these in the
KDC-REQ-BODY
+   when talking to a old server that doesn't understand
PA-PK-AS-REQ(16),
+   instead using supportedCMSTypes in AuthPack is the way to
communicate
+   supported CMS algorithms.

----

Now over to new stuff:

Comments on pkinit-22

-----

> 3.1.1  Required Algorithms
> 
>    All PKINIT implementations MUST support the following algorithms:
> 
>    o  AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
> 
>    o  Signature algorithm: SHA-1 digest and RSA.

L22.1 Should this be explicitly pointed out that this is
sha-1WithRSAEncryption (from RFC3279) this is talking about ?

-----

> 
>    o  Reply key delivery method: RSA or ephemeral-ephemeral
>       Diffie-Hellman.

L22.2 What is the MUST rsa encryption "mode": rsaEncryption
(RSAES-PKCS1-v1_5) or id-RSAES-OAEP (RSAES-OAEP) or both ?

-----

>   PKINIT uses the following algorithm identifiers [RFC2630] for
>   encrypting the reply key with the temporary key:
>
>       des-ede3-cbc           (three-key 3DES, CBC mode)
>       rc2-cbc                (RC2, CBC mode)
>       aes256_CBC             (AES-256, CBC mode)

L22.3 The name of the identifier is id-aes256-CBC, and its specified in
RFC3565, not RFC2630 (see change in L21.13). (duplicate or krb-wg rt
612).

-----

L22.4 This text should be added to the Security Considerations given
that we just dropped my request for reinstating encryptionCert:

"PK-INIT use the same RSA key for encryption and signing when doing RSA
encryption based key delivery. This is not recommended usage of RSA
keys, by using DH based key delivery this is avoided."

See "6. Overview of schemes" in PKCS2.1 [RFC3447], specificly the
quote: 

						"While RSAES-PKCS1-v1_5
   (Section 7.2) and RSASSA-PKCS1-v1_5 (Section 8.2) have traditionally
   been employed together without any known bad interactions (indeed,
   this is the model introduced by PKCS #1 v1.5), such a combined use of
   an RSA key pair is not recommended for new applications."

-----

L22.5: (various editing nits)

WrapContentInfo and WrapIssuerAndSerial should be moved to after
PA-PK-AS-REQ just like all other elements of PA-PK-AS-REQ are listed
PA-PK-AS-REQ. Both in "3.2.1 Client Request", and "Appendix A".

L22.6: (various editing nits)

There is no such structure as KRB_AS_REP, its AS-REP (see [CLAR]),
please fix them all.

-----

There is more changes needed, but this is a good start. I should have
have more time to go over the document until friday.

Love