Subject: Re: Section 3 Kerberos Revisions for comment

From: Clifford Neuman <[email-masked]>
Date: Thu, 24 Aug 2000 07:31:45 -0700 (PDT)

From: Martin Rex <[email-masked]>
   Date: Thu, 24 Aug 2000 16:23:14 +0200 (METDST)

   Martin Rex wrote:
   > 
   > I'm confused about the paragraph on integrity protected KRB_ERROR messages
   > within section 3.1.  I though that the only shared secret during a
   > failing KRB_AS_REQ would be the users secret key (=password).
   > 
   > Is there really a situation for _the_KRB_AS_REQ_exchange where
   > the KRB_ERROR reply could/would/should carry an integrity protection
   > -- i.e. which key would be used for the integrity protection?
   > 
   > -Martin
   > 
   > PS: I'm not a Kerberos guru -- I'm really sorry if the answer
   >     is obvious to the rest of you.

   I should have read 5.9.1. in the original document first ...

   OK, let's rephrase my question:
   I always thought that a TGT returned by the KDC without
   preauthentication was the weakest spot in Kerberos.

   However to my (probably naive) eyes, dictionary attacking
   the checksum of a KERB_ERROR message checksummed with
   a users private key might be easier than dictionary attacking
   the encrypted stuff of the returned TGT.

What you describe is an issue, but it is addressed in a later section
in the kerberos revisions document (see the text around "ONLY"):

  <DT>e-cksum <DD>This field contains an optional checksum for the
  KRB-ERROR message.  The checksum is calculated over the Kerberos ASN.1
  encoding of the KRB-ERROR message with the checksum absent.  The
  checksum is then added to the KRB-ERROR structure and the message is
  re-encoded.  The Checksum should be calculated using the session key
  from the ticket granting ticket or service ticket, where available.
  If the error is in response to a TGS or AP request, the checksum
  should be calculated uing the the session key from the client's
  ticket.  If the error is in response to an AS request, then the
  checksum should be calulated using the client's secret key ONLY if
  there has been suitable preauthentication to prove knowledge of the
  secret key by the client[33].  If a checksum can not be computed
  because the key to be used is not available, no checksum will be
  included.

I will consider adding an additional warning in this section too.

Clifford Neuman