[22] in GSSAPI Development
Re: Towards a compromise on addresses in channel bindings
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Apr 30 16:55:22 1991
Date: Tue, 30 Apr 91 16:54:28 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Cc: "John Linn. 508.486.6588. DTN 226-6588. 30-Apr-1991 1058"@ATHENA.MIT.EDU,
In-Reply-To: [21]
Reply-To: tytso@ATHENA.MIT.EDU
I had forgotten that SPX wants the receiver address as well as the
sender address. So allow me to modify my proposal to as follows:
typedef struct channel_bindings_struct {
OM_uint32 sender_addrtype;
gss_buffer_desc sender_address;
OM_uint32 receiver_addrtype;
gss_buffer_desc receiver_address;
#ifdef OPTIONAL
gss_buffer_t appl_specific;
#endif
} channel_bindings;
An application is required to fill in the sender and receiver address
information if it is available in its environment. An application
which, out of laziness, fills in GSS_ADDRTYPE_NULL in the sender or
receiver address type does so at its own peril....
If the appl_specific buffer really wanted, than I propose that we
specify that 1) it is mandatory that the mechanism implement it, and 2)
gss_init_sec_context implements it by signing the information in the
buffer and including it in the token, and that gss_accept_sec_context
performs a blind compare on the information. Since the information is
"application specific", it would be nonportable to do anything else.
===================
One other thing, while I'm on the subject. It would be nice if the C
binding spec indicated what things are mandatory for the mechanism
implementor and which things are optional. For example, time_req and
time_rec in gss_init_security_context(). Neither Kerberos (or SPX, so
I'm told) has any concept of the length of time that a security context
is valid. What is a valid thing for the implementor to do? Ignore
them?
- Ted
