Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA08205; Tue, 5 Dec 95 05:45:55 EST Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP id AA26886; Tue, 5 Dec 95 04:07:08 EST Date: Tue, 5 Dec 95 04:07:08 EST From: MAILER-DAEMON@MIT.EDU (Mail Delivery Subsystem) Subject: Returned mail: Deferred: Bad file number Message-Id: <9512050907.AA26886@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 RSCHOTT@CMS.CC.WAYNE.EDU... reply: read error 451 RSCHOTT@CMS.CC.WAYNE.EDU... reply: read error 451 pfenning@techfak.uni-bielefeld.de... reply: read error 451 pfenning@techfak.uni-bielefeld.de... reply: read error 451 uk-kerberos@doc.ic.ac.uk... reply: read error 451 uk-kerberos@doc.ic.ac.uk... reply: read error 421 hub.ubc.ca.tcp... Deferred: Connection refused by hub.ubc.ca >>> RCPT To: <<< 553 unknown or illegal user: DJMSYS@ritvax.isc.rit.edu 550 DJMSYS@ritvax.isc.rit.edu... User unknown 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 421 sun0.cs.plu.edu.tcp... Deferred: Connection timed out during user open with sun0.cs.PLU.edu 421 ornl.gov.tcp... Deferred: Connection refused by ornl.gov 451 Albert.Chang@cl.cam.ac.uk... reply: read error 451 Albert.Chang@cl.cam.ac.uk... reply: read error 421 telecheck.com.tcp... Deferred: Connection timed out during user open with mercury.telecheck.com 451 roland@technet.sg... reply: read error 451 roland@technet.sg... reply: read error ----- Unsent message follows ----- Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP id AA26661; Tue, 5 Dec 95 04:07:08 EST Received: by pad-thai.cam.ov.com (8.6.12/) id ; Tue, 5 Dec 1995 04:10:54 -0500 Received: from GATEWAY by pad-thai.cam.ov.com with netnews for kerberos-wrapper@cam.ov.com (kerberos@mit.edu) To: kerberos@MIT.EDU Date: 4 Dec 1995 10:35:22 GMT From: aldini@zeus.csr.unibo.it (Alessandro Aldini mat.1193) Message-Id: <49uita$o5i@sirio.cineca.it> Organization: Cineca Sender: usenet@cam.ov.com Subject: Help about Kerberos (TGT request) 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.