>Subject: GSS Server without secret key? >From: Oliver Schoett <[EMAIL PROTECTED]> >Date: Thu, 06 Nov 2003 12:17:03 +0100 >Organization: "sd&m AG, Muenchen, Germany" >To: [EMAIL PROTECTED] > >I have been playing with the Sun GSS/Kerberos sample code in > >http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/Clien >tServer.html > >and noticed that the client in this scenario needs only a Kerberos >ticket (for example, obtained from an initial Windows logon), whereas >the server needs a secret key. This creates a key management problem >for our servers, which I would like to avoid. > >Why is it that the server needs a key, when in principle, a ticket >should be enough to prove one's identity? Is there a way to avoid the >key management problem for servers?
It should be clear now (since many people have already responded to you by explaining this) that the server application needs a key to accept the security context from the GSS initiator. This key can either be stored in a keytable file, or if you are able to use user-to-user GSS you can make the application on the server logon with a username/password, and hence the logon will provide a key for accepting a context in the same way that the initiator application obtained a key using the initiating users logon credentials. However, the use of GSS user-to-user is not very common, especially in an unattended application scenario because the application needs to logon, and hence a person needs to enter the known password. If the application stores the password and uses this for the logon then you have a security problem - much worse than the 'key management problem' that you described. I therefore recommend you seriously look at using user-to-service and have key tables on each se! rver to maintain the secret for accepting the GSS context. Thanks, Tim Alsop CyberSafe Limited "The Kerberos Solution Provider" ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
