Subject: RE: New Intro Text was Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 8 Nov 2005 10:13:30 -0800

I have one more important point that I missed in my initial response.

Jeffrey Altman wrote:
>    This new method extends Kerberos to use credentials obtained from
an
>    established Public Key Infrastructure (PKI).

This is inaccurate. When the client mapping is based on the client's
public key, then there is no need for path-validation or PKI when using
PKINIT.

It is also possible to use raw public-private key pairs with PKINIT.

-----Original Message-----
From: Liqiang(Larry) Zhu 
Sent: Tuesday, November 08, 2005 10:03 AM
To: 'Jeffrey Altman'; [email-masked]
Subject: RE: New Intro Text was Re: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos

I found the original text in -29 acceptable. I did not find the new text
as better.

Here are more detailed comments:

Jeffrey Altman wrote:
> 
>    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.
>

It seems to me that Kerberos does the same thing *when* PKINIT is used,
therefore, I think the wording "in its basic form" is awkward.

>    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.

I would suggest adding back the following text to the end of this
paragraph: "Consequently, initial authentication provides a convenient
place to integrate public-key cryptography into Kerberos
authentication."

Because that is the point being made, let's make it explicit.

Also I found the following text in -29 helpful, please do not drop that.

   As defined in [RFC4120], Kerberos authentication exchanges use
   symmetric-key cryptography, in part for performance.  One
   disadvantage of using symmetric-key cryptography is that the keys
   must be shared, so that before a client can authenticate itself, he
   must already be registered with the KDC.

This text suggests the trade-off of using PKINIT. It is helpful to point
out that symmetric-key cryptography does have a lot better performance.
And avoiding some form of the pre-registration is a significant
advantage of using PKI. 

>    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.

[lzhu] I prefer "initial authentication" over "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.

[lzhu] this claim is controversial. I would also suggest that using
delegation is not the most significant advantage.  Listing it here is
misleading rather than convincing.

>    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.

[lzhu] this claim is controversial too. In addition, it is either too
generic or vague that I did not find it helpful when I read it.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Altman
Sent: Tuesday, November 08, 2005 8:24 AM
To: [email-masked]
Subject: Re: New Intro Text was Re: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos

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

Jeffrey Altman wrote:
> 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: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 8 Nov 2005 11:44:52 -0800

I agree with Chaskiel M Grundman and you that it is more secure to use a
randomly-generated long public-private key pair than a weak password.
And users typically can not remember strong passwords; therefore it is
beneficial to use PKINIT for initial authentication.

This seems to be helpful/useful, I would not object adding this to the
existing text in -29.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Tung
Sent: Tuesday, November 08, 2005 11:33 AM
To: [email-masked]
Subject: Re: New Intro Text was Re: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos

Liqiang(Larry) Zhu wrote:
> This is because it all depends on the size of the key, for example a
256
> bit AES key is not easier to crack than a 1024 bit RSA key pair, and I
> just do not find the text helpful. 

It is easier if the 256-bit AES key is password-derived.  That is a
common case with vanilla Kerberos.

> If we want to convince someone to implement/adopt PKINIT with this
text,
> it is not sufficient then. Hypothetically if this protocol makes the
> attacker's life just twice as harder, I would not be convinced.

If the difference is between password-derived key and randomly-generated
public key pair, the difference is much more than a factor of two.

-- 
Brian Tung <[email-masked]>
* etiam non me contradixisti * et cuniculi et vulpeculae moriuntur *
USC Information Sciences Institute