Key Managemet

[Marcus Watts]

bacolod at hushmail.com writes:
> 2 Key management questions:
> 
> 1. It is my understanding that client secret keys must not be passed in the clear.  If someone ever gets hold of a clients secret key, what exactly can they do to compromise Kerberos?

That "someone" can impersonate that client principal to kerberos, can get service
tickets to any service on behalf of that client, might be able to decode
past sessions if "someone" arranged to capture a lot of network traffic,
and probably also that someone can change the client's "key"/password
to a new one.  Basically, lots of bad things, to that client.
Other principals should not be so affected (unless, of course, the client
had special rights to kerberos itself or other services that might indirectly
affect kerberos.)

> 
> 2. I'll get to test this soon but until then, does anyone know what might happen in the following scenario:
> 
> ATM switch is a Kerberos client
> ATM switch secret key needs to be updated
> The "most practical" way to update the secret key on the ATM switch is to log onto it via Kerberized (w/ data encryption on) telnet (ssh not available) and perform the ATM switch "Get secret key" function which uses either FTP or HTTP (scp not available) (I'm hoping Kerberized FTP is available).
> 
> My question is, what happens to the established Kerberized telnet session when the ATM switch sectret key is updated?
> 
> Out of band management would be nice but it isnt very practical in this particular application.

Nothing happens.  The service key is only used when the connection is
initially made.  For this application you probably don't care, but for
a "high profile" service where many users might have old session
tickets which should be good for up to 24 yours (such as afs), you would
want to use
	-keepold
when you use kadmin "ktadd" to extract the new keys.

				-Marcus Watts
				UM ITCS Umich Systems Group