[15] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

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
	- 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
	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.

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.


home help back first fref pref prev next nref lref last post