[15] in Kerberos_V5_Development
thoughts on a new kerberos library I/F
wesommer@ATHENA.MIT.EDU (wesommer@ATHENA.MIT.EDU)
Wed Dec 13 13:31:40 1989
Kerberos Library components:
- DES library:
Pure encryption package.
includes des_ecb_encrypt, des_cbc_encrypt, des_string_to_key (?).
- May include random key generator, built on a portable RNG
interface.
- does not include read_password.
- ticket cache
cache for tickets & session keys; should allow multiple
identitities in ticket file with appropriate separation.
- key database
main op: hand it server identity + kvno, yields key
also includes op to add new key, delete old key.
another form of this would support the Davis & Swick "two tgt"
approach for things like X server authentication.
- kdc database
look up based on principal name, kvno; yield key + additional
info.
should allow multiple key,kvno pairs for a principal.
(run over the registry; we may not do a dbm implementation).
- random key generator (for KDC use, primarily).
- os interface (provide implementation for posix or bsd4.3)
includes things like:
- open/read/write/close/lock file.
- "read password" function.
- network operations (send/recv udp datagrams)
- getting, comparing time stamps.
- protocol decoders/encoders (for various messages & submessages).
These marshall or marshall+encrypt, or unmarshall or
decrypt+unmarshall the various protocol messages. The only errors
these can generate would result from mangled packets or data.
- "association management"; layered on ticket cache, decoders.
Runs the "protocol engine"; handles key & ticket management, makes
decisions based on the definition of the protocol.
--------------------------------
interface ideas:
data structures would include "client identity", "server identity",
"client association", and "server association"
"client identity"-> pointer to a ticket cache.
"server identity"-> pointer to a key database.
"client association"-> client id + server id + session key + ticket
+ misc data (options, etc), ptr to client identity.
"server association"-> client id + server id + session key
+ misc data, ptr to server identity.
[client, server association can have pointers to "encryption
objects" to allow for multiple encryption algorithms.
Abstract interface to block-based stream cipher:
- encrypt_bytes (expkey, in, out, count);
- decrypt_bytes (expkey, in, out, count);
- expand_key (key, expkey)
- int block_size
- int key_size
- int expkey_size
--------------------------
"flow" of control:
client finds its identity (library routine returns "default" identity).
client identifies server
------ krb_mk_req does this:
v client creates "client association" to server from identity, server name.
^ client generates authenticator.
------
client sends authenticator to server..
server receives authenticator
server creates "server association" from authenticator and server identity.
("krb_rd_req")
server generates mutual authenticator.
server sends mutual authenticator to client
server either hangs onto association or destroys it, depending....
------
client receives mutual authenticator
client checks mutual authenticator against the "association" object.
---------------------------------
Feature check (from v5 proto spec).
1) desired lifetimes on tickets.
- When building client identity, this gets passed to constructor function.
- The "create_association" operation might want a *minimum* valid
timestamp parameter (which would generate an error on the client side
if the authenticator would expire before dd/mm/yy hh:mm:ss).
- information on lifetime is visible as part of client and server
association; server can may authorization decisions based on that.
2) renewable bit:
- passed to client id constructor as a flag.
3) mutual auth bit:
- set when building authenticator.
4) forwarding: set on association creation.
5) forwardable: set on identity creation.
6) proxy: set on assoc creation.
7) proxyable: set on identity creation.
8) postdate (+ date): set on identity creation.
9) renewal/validation:
- perhaps handled automagically by the library on association creation.
a flag bit to association creation could suppress this.
11) krb_mk_safe & krb_mk_priv, (and recvers) get handed an "association"
object as well.
------------------------
