Subject: RE: IETF krb-wg Jabber log

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 3 Mar 2004 23:43:43 -0800

Isn't the canonicalized cname encrypted in the returned TGT? There is a
duplicate cname field out there in cleartext and and it is unsigned, but
perhaps you can reject the ticket if these two do not match.

On page 126:

      Ticket          ::= [APPLICATION 1] SEQUENCE {
              tkt-vno         [0] INTEGER (5),
              realm           [1] Realm,
              sname           [2] PrincipalName,
              enc-part        [3] EncryptedData -- EncTicketPart
      }

      -- Encrypted part of ticket
      EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
              flags                   [0] TicketFlags,
              key                     [1] EncryptionKey,
              crealm                  [2] Realm,
              cname                   [3] PrincipalName,
              transited               [4] TransitedEncoding,
              authtime                [5] KerberosTime,
              starttime               [6] KerberosTime OPTIONAL,
              endtime                 [7] KerberosTime,
              renew-till              [8] KerberosTime OPTIONAL,
              caddr                   [9] HostAddresses OPTIONAL,
              authorization-data      [10] AuthorizationData OPTIONAL
      }

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Wednesday, March 03, 2004 11:17 PM
To: Jeffrey Altman
Cc: [email-masked]
Subject: Re: IETF krb-wg Jabber log

Wow -- this was a busy meeting!

There's a lot here to digest, and some items for me to address.  I'll
try to get to it tomorrow.

Briefly though, on the cname field of AS-REQs:

 - I believe it is to be required, always, in AS-REQs...

 - ...but I offered some alternatives should the KDC-figures-out-my-
   princ-name-from-my-cert feature be really desireable...

 - ...and I explained that without any additional steps this feature
   leaves the client open to an active attack (that perhaps we don't
   care about if every cert a KDC recognizes maps to one and only one
   princ name -- this was one of the options I offered).

 - The alternatives I offered stand, and, as discussed at the meeting, a
   pre-auth type to sign the AS-REQ in the AS-REP would be one
   possibility.  In extensions we should not only pursue Signed, but
   also try to ensure that every reply signs the corresponding request.

More later.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Mar 2004 02:52:24 -0600

> perhaps you can reject the ticket if these two do not match.

The issue is that an active attacker could have modified the request to
add the cname field and the client won't be able to tell from the AS-REP
(assumming that the attacker picked a name that he/she knew would the
client's cert would be authorized to).

In practice this attack would be of very limited value, and if certs
map to no more than one princ name each then there is no issue at all.

Myself I can see value in the client not having to know its principal
name -- it's bad enough that it has to know its cert and private key! :)
I just want to make sure we understand, and preferably address, the
problems with this feature as is.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Mar 2004 03:06:17 -0600

This should have read:

> are authorized to no more than one princ name each then there is no
> issue at all.