[2936] in Kerberos
Re: About principals' secret keys & attacks
daemon@ATHENA.MIT.EDU (Michael T. Stolarchuk)
Tue Dec 21 09:15:04 1993
To: Scott Dawson <sdawson@engin.umich.edu>
Cc: Carlos Horowicz <carlos@athea.ar>, kerberos@MIT.EDU
Date: Tue, 21 Dec 1993 08:53:34 -0500
From: "Michael T. Stolarchuk" <mts@terminator.rs.itd.umich.edu>
"It's been a few years since I looked at it, but the ASN.1 notation can
make life even easier for the attacker."
"I personally regard this attack -- requesting TGT's for various
individuals --as the single biggest problem with Kerberos. I believe
that there's an enhancement to V5 -- and I don't recall if it's an
option or part of the basic protocol -- to provide for
preauthentciation of the TGT request. That's a very important change."
Yep, ASN.1 can help by providing verifiable text to check, but sommerfeld
points out that the encryption/decryption checksum is much more of
an appropriate test for correctneness of decryption. Just in case
it hasn't been mentioned, in Krb5 many of the encrypition methods
provide a checksum of the encrypted data to VERIFY the encryption went well.
In the sollowing message, sommerfled also describes the next iteration
of DCE login.
------- Forwarded Message
Date: Wed, 17 Nov 1993 22:07:08 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
In-Reply-To: <199311180116.UAA14338@terminator.rs.itd.umich.edu> (mts@terminator.rs.itd.umich.edu)
Subject: Re: Third party proxy question.
Among other things, yes.
kerberos v5 adds a CRC inside the (CBC mode) encryption so you know
when you decrypt successfully; this was used instead of the PCBC mode
in kerberos v4 because it was discovered that PCBC mode resynchronizes
after swapped ciphertext blocks..
The information you're missing is that with DCE 1.1, the login
exchange goes (roughly):
(terminology:)
P, Kp: principal logging in, his password-derived key
C, Kc: client machine that `principal' is logging in to, its key
TGS, Ktgs: ticket granting service, its key.
Ktmp: temporary key.
Ta->b: ticket from A to B: {A->B, Ka->b, timestamps, ...}Kb
Ka->b: key for ticket from A to B
request:
P,C -> TGS
AS request: P->TGS, C, {{timestamp, Ktmp}Kp}Kc
At this point, the KDC decrypts the {timestamp, Ktmp} message using
Kc, then Kp, then validates that the timestamp is current, encrypts
the TGS session key using Ktmp, and generates the response.
response:
TGS -> P,C
AS reply: Tp->tgs, {Kp->tgs}Ktmp
There is no "bare" ciphertext encrypted with Kp in this exchange; all
other keys are assumed to be full-strength keys.
DCE 1.0.x doesn't do this yet, however, we knew that this was coming
and didn't want to paint ourselves into a corner...
- Bill
------- End of Forwarded Message
