[7810] in Kerberos
Re: Mundane kerberos question: srvtab management
daemon@ATHENA.MIT.EDU (Rich Salz)
Tue Aug 20 04:58:43 1996
To: kerberos@MIT.EDU
Date: 20 Aug 1996 03:21:55 GMT
From: rsalz@osf.org (Rich Salz)
In <4uumcu$2il@brisbane.celsius.oz.au> gaga@celsius.oz.au (Gary Gaskell) writes:
>Well, I'm sure that some OSF folks are listening. The DCE enhancements
>to Kerberos v5 add some tools for the updateing of server keys. I
>don't have any DCE documentation at this office, so don't read this
>as gospel. But DCE provides some assistence. Based on the server
>key that is already available, the key may be updated. Of course
>if the key is compromised, any future keys will also be compromised,
>as the former key is used to secure the transmission of the new key.
Let me try to explain what DCE provides. The DCE terminology is a
"keytable," or "keytab". In DCE, keys have a type (currently
always private-key) a
There is a set of API's, sec_key_XXX, that let you do the following (among
others):
login from data in a keytab
Iterate over all principal/key tuples
Iterate over all keys for a given principal
GC old keys
Change the key in the file, and with the DCE KDC, either specified
or a strong random key
Because of US Export requirements and patent restrictions, the key-change
protocol has no forward secrecy; cracking key #n will let you determine
key n+1. These API's have been in DCE from the beginning, more or less.
In DCE 1.1 the dced host daemon provides a set of remote operations to
manipulate keytabs, including creating them, adding/removing keys, and
retrieving their contents. For security purposes, this uses DCE privacy
(DES encryption of the application-level data), which is normally not
available in international products created by US companies. Because of
this, a special commandline flag exists in dced to not require privacy
while resopnding to remote keytab operations.
Hope this helps. I designed the dced stuff, so should be as able as
anyone to answer questions about DCE's remote management.
/r$
