Subject: pk-init22 part 1

From: Love <[email-masked]>
Date: Wed, 05 Jan 2005 15:31:07 +0100

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 05 Jan 2005 11:50:30 -0500

On Wednesday, January 05, 2005 15:31:07 +0100 Love <[email-masked]> 
wrote:

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

ContentType and IssuerAndSerialNumber come from CMS.  They are wrapped, 
except for one occurrance of ContentType which was apparently missed; this 
issue is the subject of #768 which I opened yesterday.

SubjectPublicKeyInfo, AlgorithmIdentifier, and Name all come from
PKIXExplicit88.  These are presently not wrapped; should they be?
This issue is now ticket #773.

>    So given this, the [2] needs to split in two, CMS as protocol and CMS

The need for a reference to RFC3565 is why #612 is still open.
I have opened #774 for CMS reference updates.

> +   supported CMS algorithms.

As far as this document is concerned, there is no such thing as a PKINIT 
implementation that doesn't understand PA-PK-AS-REQ(16).  My understanding 
was that enctype numbers would be used for the few "old" types where they 
had already been assigned, and that OID's would be used for all new 
algorithms.

> sha-1WithRSAEncryption (from RFC3279) this is talking about ?

Yes.  This is spelled out in 3.1.3, but should be made explicit here as 
well.  This is #775.

> (RSAES-PKCS1-v1_5) or id-RSAES-OAEP (RSAES-OAEP) or both ?

Actually, the required reply key delivery method is DH.  For some reason 
this text was changed in -22 to refer to RSA, which is not the required 
method.  This is the subject of #766 which I opened yesterday.  I have 
updated that ticket to point out that if we want to require RSA, we must be 
specific about which algorithm is required.

> in RFC3565, not RFC2630 (see change in L21.13). (duplicate or krb-wg

Right.

> that we just dropped my request for reinstating encryptionCert:

Added as #776.

> There is no such structure as KRB_AS_REP, its AS-REP (see [CLAR]),

The PDU type is called AS-REP; its type is KRB_AS_REP.  The text of [CLAR] 
itself is inconsistent in its usage; sometimes it uses AS-REP and sometimes 
KRB_AS_REP.  I agree that PKINIT should be consistent in its usage, not 
only for this message but for all Kerberos PDU types.  I have created #777 
for this issue.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Jan 2005 20:28:54 -0500

>>>>> "Love" == Love  <[email-masked]> writes:

    Love> Let start off with old stuff.

    Love> Old Comments

    Love> ----

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

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

My gut feeling is that it should not be wrapped.  I cannot justify
this.
    Love> L21.11 I think the client MUST NOT send the CMS kerberos
    Love> encryption types if it only send the new TDB pa-type number
    Love> but only use the new supportedCMSTypes.

This seems to disagree with the Boulder consensus.

    >> o Signature algorithm: SHA-1 digest and RSA.

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

    Love> -----

    >>  o Reply key delivery method: RSA or ephemeral-ephemeral

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

I'd prefer oaep, but I bet I can't get a consensus on that.

    Love> -----

--Sam

---

From: Love <[email-masked]>
Date: Sat, 08 Jan 2005 15:42:47 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> ContentType and IssuerAndSerialNumber come from CMS.  They are
> wrapped, except for one occurrance of ContentType which was apparently
> missed; this issue is the subject of #768 which I opened yesterday.
>
>

SubjectPublicKeyInfo and AlgorithmIdentifier is quite simple types and
might/will be processed by the pkinit implementation itself. So I think
they don't need to be wrapped.

Name on the other hand is quite a complex type, and will need to be
processed by the CMS/X509 library, so it would probably be good if it was
not parsed directly in the by the pk-init decoder.

CertificateIndex doesn't need to be encoded ince its already inside an
OCTET STRING of TYPED-DATA.

> As far as this document is concerned, there is no such thing as a
> PKINIT implementation that doesn't understand PA-PK-AS-REQ(16).  My
> understanding was that enctype numbers would be used for the few "old"
> types where they had already been assigned, and that OID's would be
> used for all new algorithms.

Is there any current implementations that care about these numbers ?

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 23 Jan 2005 20:46:48 -0500 (EST)

> they don't need to be wrapped.

I've seen two comments in favor of this position, and none opposed.
So unless there is more, these will be left unchanged.

> not parsed directly in the by the pk-init decoder.

Anyone care to comment on this?  We need to make a decision before this
document can progress.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 23 Jan 2005 20:57:21 -0500 (EST)

> I'd prefer oaep, but I bet I can't get a consensus on that.

In pkinit-21, the only required method was DH.  A change to this requires
a WG consensus.  I saw no discussion of this change in the WG prior to the
publication of pkinit-22, and I've seen _zero_ comments supporting it
since then.  Unless there is discussion on this point, the
required-to-implement reply key delivery method will be DH.

We cannot say that "DH or RSA" is required -- a requirement of this form
does not serve the purpose of having REQUIRED algorithms, which is to
promote interoperability.

We cannot make "RSA" one of the required methods -- as Love points out, we
must be specific about which mode is required.

I expect pkinit-23 to be submitted shortly with this issue left
unresolved.  I would like to see discussion to resolve this issue within
the next 2 weeks or so.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Sun, 23 Jan 2005 23:03:34 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    >> Name on the other hand is quite a complex type, and will need
    >> to be processed by the CMS/X509 library, so it would probably
    >> be good if it was not parsed directly in the by the pk-init
    >> decoder.

    Jeffrey> Anyone care to comment on this?  We need to make a
    Jeffrey> decision before this document can progress.

I presented a very weak objection to wrapping this type and Love
presented a substantiated explanation of why you want to wrap it.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 23 Jan 2005 23:23:14 -0600

> Anyone care to comment on this?  We need to make a decision before this

I think Love's right -- Name is sufficiently complex that re-encoding
could be a big pain.