[640] in Kerberos_V5_Development

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

Proposed interface to sendauth/recvauth

tytso@ATHENA.MIT.EDU (tytso@ATHENA.MIT.EDU)
Fri Mar 8 14:39:19 1991

I propose that the following interfaces be placed in the Kerberos
library.  The first two are the interfaces for sendauth and recvauth.  

krb5_error_code krb5_sendauth(/* IN */
			      int fd,
			      char *appl_version,
			      krb5_principal client,
			      krb5_principal server,
			      krb5_flags ap_req_options,
			      krb5_checksum *checksump,
			      /* IN/OUT */
			      krb5_creds *credsp,
			      krb5_ccache ccache,
			      /* OUT */
			      krb5_int32 *seq_number,
			      krb5_keyblock **newkey,
			      krb5_error **error,
			      krb5_ap_rep_enc_part **rep_result);

krb5_error_code krb5_recvauth(/* IN */
			      int fd,
			      char *appl_version,
			      krb5_principal server,
			      krb5_address *sender_addr,
			      krb5_pointer fetch_from,
			      rdreq_key_proc keyproc,
			      krb5_pointer keyprocarg,
			      char *rc_type,
			      /* OUT */
			      krb5_int32 *seq_number,
			      krb5_principal*client,
			      krb5_ticket **ticket,
			      krb5_authenticator **authent));

If any of the OUT arguments contain the NULL argument, that field will
not be returned to the caller.  If seq_number is NULL, sendauth/recvauth
will not try to exchage a sequence number.  In krb5_recvauth, rep_result
is only filled in if mutual authentication is being performed.  In
krb5_sendauth, seq_number is only filled in (and sent over) if mutual
authentication has been requested by the caller.

--------------------------------------------

These two routines are used as an easy way to send messages across the
wire.  Recvauth and sendauth use them to send the ap_req and ap_rep
mesages across the wire.  The reason why I think they should go in the
library (probably libos) is that the user needs an easy way to ship
mk_priv and mk_safe messages across the wire too.

They are currently implemented by sending over the length of the buffer
in network byte order, and then sending over the buffer itself.  The
reasn why I didn't use an ASN.1 encoding is that in ASN.1, you don't
necessarily how large the message will be until the message is actually
finished, and I didn't want to introduce a large, painfully slow ASN.1
parser that would read() a little bit, parse some ASN.1 junk, read()
some more, etc.  I think it's too painful, and too slow because of the
number of context switches that you have to do.

krb5_error_code krb5_read_message(int fd, krb5_data *inbuf);

krb5_error_code krb5_write_message(int fd, krb5_data *outbuf);

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