Subject: Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

From: Tom Yu <[email-masked]>
Date: Sun, 06 Nov 2005 23:34:05 -0500

Minor editorial nit:

pkinit> Interoperability note: Some implementations may not be able to
pkinit> decode wrapped CMS objects encoded with BER but not DER;
pkinit> specifically, they may not be able to decode infinite length
                                                     ^^^^^^^^
                                                     indefinite
pkinit> encodings.  To maximize interoperability, implementers SHOULD
pkinit> encode CMS objects used in PKINIT with DER.

I am still looking at the rest of it.

---Tom

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 07 Nov 2005 15:10:37 -0800

Here is proposed alternate introduction text for PKINIT:

1.  Introduction

   In its basic form, the Kerberos Network Authentication Service (V5)
   [RFC4120] Key Distribution Center (KDC) using symmetric cryptography
   issues Ticket Granting Tickets (TGTs) to clients encrypted with a
   secret key known to both the client and the KDC.  RFC4120
   further describes pre-authentication mechanisms that are based upon
   this shared secret or passwordless hardware authentication methods.

   The advantage afforded by the TGT is that the client exposes his
   long-term secrets only once.  The TGT and its associated session key
   can then be used for any subsequent service ticket requests.  One
   result of this is that all further authentication is independent of
   the method by which the initial authentication was performed.

   This document, Public Key Cryptography for Initial Authentication in
   Kerberos [PKINIT], defines a new pre-authentication method that uses
   public key cryptography for Kerberos initial ticket acquisition.
   This new method extends Kerberos to use credentials obtained from an
   established Public Key Infrastructure (PKI).

   There are several benefits obtained from integrating PKI and Kerberos
   as part of the Kerberos initial authentication.  Kerberos is the only
   authentication mechanism that supports single sign-on across multiple
   hosts and organizational authentication domains via use of delegation
   (ticket forwarding) and cross-realm.  PKINIT extends the use of PKI
   credentials to Kerberos infrastructure providing users with an
   enhanced single sign-on capability.

   The use of public key certificates instead of password based long
   term keys when performing the initial authentication increases the
   effort necessary to execute an offline attack on the client's long
   term secret.  Depending on the implementation it may also be possible
   to construct a dynamic process by which clients are registered with
   the KDC.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 08 Nov 2005 08:24:24 -0800

Here are the reasons I want to see new intro text:

 * the introduction should explain what this document achieves to a
   reader who is starting from 4120

 * the previous introduction is dervied from the text used when pkinit,
   pktap and pkcross were one document.   the text explaining why the
   initial ticket exchange is a convenient location to join PKI to
   kerberos is out of place without the rest of the text that was
   removed

 * the previous introduction describes the potential dynamic
   registration aspects of using certs which was a much more significant
   goal in the original combined pkinit, pktap, pkcross document

 * there needs to be better text explaining the delegation benefits of
   joining Kerberos and PKI for the PKI community.

I am sure the below text is not perfect but it was my first attempt at
a re-write.   I have received comments from Larry in private and I will
work to produce an improved second edition.

Jeffrey Altman

---

From: Tom Yu <[email-masked]>
Date: Tue, 08 Nov 2005 17:14:41 -0500

Regarding to Love's comment in the WG session, I have examined Section
3.2.2 of pkinit-29 and found that TD-DH-PARAMETERS is in fact
underspecified.  AlgorithmIdentifier is basically a typed hole, with
the contents being an ASN.1 type identified with an OID.  Section
3.2.2 does not specify what OID or ASN.1 type to use in
TD-DH-PARAMETERS.  I have looked at the the referenced standard, IEEE
1363, which does not itself specify any OIDs or ASN.1 types as far as
I can tell.  IEEE 1363 only really specifies the math behind using
DH.

What is probably meant is the OID and ASN.1 type in RFC 3279
associated with Diffie-Hellman domain parameters, which is in turn
based on ANSI X9.42 (which I don't think I have access to).

---Tom