Subject: RE: Some questions on the password cracking issue

From: "PATO,JOE (HP-PaloAlto,ex1)" <[email-masked]>
Date: Mon, 2 Dec 2002 17:13:02 -0500

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Monday, December 02, 2002 4:31 PM
To: [email-masked]
Subject: Re: Some questions on the password cracking issue

    >>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, Dec 02, 2002 at 04:07:46PM -0500, Sam Hartman
    Nicolas> wrote:
    >> 
    >> 
    >> 1) Are the set of keyed machines important enough as Kerberos
    >> clients that we should consider optimizing a solution for that
    >> case?

    Nicolas> Maybe.  Would we be increasing the usage of the client's
    Nicolas> long term key in the process?  Is that an issue?

    Sam> We'd be increasing the usage of the client long-term key.
    Sam> It's random; I think that's much more acceptable than a
password-based key.

In DCE RFC 26, there is no increase in the use of the client key. In the DCE
context the client machine had acquired a TGT for other services any way.
Encryption of the per-user information occurs under a random subkey which is
itself encrypted under the session key from the TGT:

      The "PADATA-ENC-THIRD-PARTY" pre-authentication type provides a
      mechanism for the KDC to verify that the client knows a principal's
      key without exposing that key to network eavesdroppers.  The padata
      contains three components: a ticket granting ticket (TGT) for the
      third party principal; a random key encrypted using the session key
      of the TGT; and a buffer encrypted using the client principal's key
      then encrypted under the preceding random key.  Specifically:

            PADATA-ENC-THIRD-PARTY ::= SEQUENCE {
                    ticket       [0] Ticket,
                    enc-subkey   [1] EncryptedData,
                            -- encrypted using the ticket session key
                    enc-userinfo [2] EncryptedData
                            -- encrypted using the subkey
            }

            PADATA-ENC-THIRD-PARTY-SUBKEY ::= EncryptionKey

            PADATA-ENC-THIRD-PARTY-ENC-USERINFO ::= EncryptedData
                    -- encrypted using the key of the client principal

            PADATA-ENC-THIRD-PARTY-USERINFO ::= PADATA-ENC-USERINFO

      When a client principal is about to initiate a KRB_AS_REQ (initial
      authentication exchange with the KDC) it obtains the TGT for the
      third party sponsor, a usable version of the random subkey and a
      version of the same key encrypted under the session key in the third
      party's TGT.  The ticket identifies the third party sponsor for the
      authentication exchange and establishes a shared key between the KDC
      and the third party sponsor.  Note that the third party sponsor must
      obtain a TGT to the cell of the client principal, since the ticket
      passed in this message must be understood by the authentication
      server of the client's home cell.

Joe Pato                                   HP Labs
Principal Scientist                        1 Cambridge Center, 11th Fl
Trust, Security & Privacy                  Cambridge, MA   02142
Trusted Systems Lab - HP Labs              Phone: (617) 551-7648 
<mailto:[email-masked]>                   HP Telnet: (650) 857-2774
<http://www.hpl.hp.com/personal/Joe_Pato>  Fax 1: (617) 551-7650
<http://www.hp.com/security>               Fax 2: (781) 674-0142