Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA16000; Tue, 5 Dec 95 09:09:03 EST Received: from Lehman.COM by MIT.EDU with SMTP id AA04332; Tue, 5 Dec 95 07:24:47 EST Date: Tue, 5 Dec 95 07:24:47 EST From: MAILER-DAEMON@MIT.EDU (Mail Delivery Subsystem) Subject: Returned mail: Deferred: Bad file number Message-Id: <9512051224.AA04332@MIT.EDU> To: owner-kerberos@MIT.EDU ----- Transcript of session follows ----- 451 Mack@rus.uni-stuttgart.de... reply: read error 451 Mack@rus.uni-stuttgart.de... reply: read error 451 pfenning@techfak.uni-bielefeld.de... reply: read error 451 pfenning@techfak.uni-bielefeld.de... reply: read error 451 zucco@gardenia.saclay.cea.fr... reply: read error 451 zucco@gardenia.saclay.cea.fr... reply: read error 451 hussien@masi.ibp.fr,hua@masi.ibp.fr... reply: read error 451 hussien@masi.ibp.fr,hua@masi.ibp.fr... reply: read error >>> RCPT To: <<< 553 unknown or illegal user: DJMSYS@ritvax.isc.rit.edu 550 DJMSYS@ritvax.isc.rit.edu... User unknown 451 cmsdadam@kryten.cms.livjm.ac.uk... reply: read error 451 cmsdadam@kryten.cms.livjm.ac.uk... reply: read error 451 Yves.Dherbecourt@der.edf.fr... reply: read error 451 Yves.Dherbecourt@der.edf.fr... reply: read error 421 california.sandia.gov.tcp... Deferred: Connection timed out during user open with california.sandia.gov 451 kejzlar@kirke.zcu.cz... reply: read error 451 kejzlar@kirke.zcu.cz... reply: read error 421 sun0.cs.plu.edu.tcp... Deferred: Connection timed out during user open with sun0.cs.PLU.edu 451 emmanuel.kordomenidis@almac.co.uk... reply: read error 451 emmanuel.kordomenidis@almac.co.uk... reply: read error 451 jhlee@minkowski.etri.re.kr... reply: read error 451 jhlee@minkowski.etri.re.kr... reply: read error 451 houle@acns.fsu.edu... reply: read error 451 houle@acns.fsu.edu... reply: read error 451 Albert.Chang@cl.cam.ac.uk... reply: read error 451 Albert.Chang@cl.cam.ac.uk... reply: read error 421 dataplex.net.tcp... Deferred: Connection timed out during user open with MAIL.dataplex.net 421 telecheck.com.tcp... Deferred: Connection timed out during user open with mercury.telecheck.com 451 laurea@deis93.cineca.it... reply: read error 451 laurea@deis93.cineca.it... reply: read error 451 roland@technet.sg... reply: read error 451 roland@technet.sg... reply: read error ----- Unsent message follows ----- Received: from Lehman.COM by MIT.EDU with SMTP id AA04139; Tue, 5 Dec 95 07:24:47 EST Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id HAA22868; Tue, 5 Dec 1995 07:25:46 -0500 Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3) id tmp022860; Tue Dec 5 07:25:20 1995 Received: from kublai.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA27802; Tue, 5 Dec 95 07:25:19 EST Received: from badger.lehman.com by kublai.lehman.com (4.1/Lehman Bros. V1.6) id AA09422; Tue, 5 Dec 95 07:25:11 EST Received: by badger.lehman.com (SMI-8.6/Lehman Bros. V1.5) id HAA02060; Tue, 5 Dec 1995 07:25:10 -0500 Date: Tue, 5 Dec 1995 07:25:10 -0500 Message-Id: <199512051225.HAA02060@badger.lehman.com> To: aldini@zeus.csr.unibo.it (Alessandro Aldini mat.1193) Cc: kerberos@MIT.EDU Subject: Re: Help about Kerberos (TGT request) In-Reply-To: <49uita$o5i@sirio.cineca.it> References: <49uita$o5i@sirio.cineca.it> From: "Richard Basch" On , 4-December-1995, "Alessandro Aldini" wrote to "kerberos@MIT.EDU" saying: > I read from "Firewalls and Internet Security" about the Kerberos > Authentication System : > Kerberos principals may obtain tickets for services from a special server > known as the Ticket Granting Server (TGS). > The client "speaks" to TGS with a private key and he obtains this key at > session-start time from KDC (key distribution centre). The client > makes a request to the KDC to obtain this key (and other information for > the TGS) and the KDC reply with an encrypted messagge; the key used for this > messagge is > the client private key, so the KDC must know the private key of every user. > The client key is derived from a noninvertible transform of the user's > typed password. I suppose that KDC uses a secret algorithm to obtain the > private key from the password and every client knows his own password and > key but not the algorithm password-to-key. Is it true ? Otherwise how can > KDC know every client private key ? > Please answer me in e-mail. Thank you for your help. > CIAO, Alessandro. The algorithm for converting the password into the key is well known. The way it works is: User issues a request to the KDC saying send me a ticket with which I can present you with other tickets without needing my password again. The KDC responds with a TGT encrypted in the user's key (derived from his password). The user can then decrypt the KDC response which gives him a TGT and a ticket granting session key. All future ticket requests are done by sending the TGT (which has his authentication name and the ticket granting session key encoded in it and which only the KDC can unravel because it is encrypted in a key known only to the KDC) along with whatever other tickets he needs. These ticket requests are always authentic because only the user who had the original password could have possibly gotten the TGT. The new tickets are encrypted in the ticket granting session key, so only the user can decrypt it. I have oversimplified some things when it comes to Kerberos V5, as the above attack allows one to make one TGT request, and keep trying to decrypt the TGT offline with lots of keys (this is possible in V4). In V5, there are also pre-authentication routines that can be enforced. So, basically, think of Kerberos as being a set of envelopes that can be opened only if you know the seal... Here is a quick picture: [password/TGT session key] --------------------------------------------------------- | | | session key | | | | | | [service key] | | ----------------------------------------- | | | | | | | authentication name | | | | session key | | | | | | | ----------------------------------------- | | | | | --------------------------------------------------------- There is more information. However, this model does show how a session key is sent to the user and the service that the user is sending the ticket to, without the session key being disclosed. Each service also has a key associated with it, just like each user. From the KDC perspective (in V4), in fact, they are equivalent. -- Richard Basch URL: http://web.mit.edu/basch/www/home.html Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu 101 Hudson St., 33rd Floor Fax: +1-201-524-5828 Jersey City, NJ 07302-3988 Voice: +1-201-524-5049