Subject: RE: Questions on RFC2078

From: [email-masked] (Guang Li)
Date: Thu, 22 Jan 1998 09:36:54 GMT

Fengmin Gong & jl writes, excerpting:

	> 2) The kind of scenarios I face also desire another
	> feature that is missing from RFC2078 spec, i.e., a kind
	> of "delegation mode" per-message protection call. For example,
	> a GSS_Wrap_and_send() call will do all the things that
	> GSS_Wrap() does now, but in addition will send the wrapped
	> message out of the network protocol stack instead of
	> returning it to the caller.  Although I could make do by 
	> returning the original message to the caller as appropriate, 
	> it does have some efficiency implication.
	> 
	> I realize that this requirement seems to run against the
	> GSS-API principle of "protocol environment independence"
	> but I can also argue otherwise.  Availability of such 
	> delegation feature will be mechasnism dependent, similar
	> to QoP support; it can be made known to the applications
	> at context establishment item using those service flags;
	> separate per-message calls avoid changing any of the
	> existing calls.
	> 
	Mechanism dependence issues aside, this sort of coupling could also be
	specific not only to protocol environments but also to the communication
	access APIs used within an end system. If appropriate in a particular
	environment, it's certainly possible to wrap GSS calls within a veneer
	which also bundles invocation of communications-level calls; would the
	incremental efficiency obtainable by implementing such a veneer below
	the declared GSS boundary be sufficiently motivating relative to a
	separate modular layer above GSS?

this is indeed the case for many GSS applications, notably the
OMG's SECIOP. BTW, GSS manages its own buffers, which introduces
unnecessary message copys, and is apparently againest high-performance
protocol design principles.

Dr. Guang X. Li
Information Technology
SBC Warburg Dillon Read
Swiss Bank Corporation
1 Finsbury Avenue
London EC2M 2PP

---

From: Martin Rex <[email-masked]>
Date: Mon, 26 Jan 1998 19:44:56 +0100 (MEZ)

> protocol design principles.

Those "unecessary" message copies make the gss-api much simpler and
more robust as an API, both in the gssapi mechanism and the application.
Neither has to care about alignment, blocksize, padding and the case
that the supplied buffer is too small.  The performance impact should
in general be less than 2%, so basically insignificant.

For message integrity only one could use gss_getmic()/gss_verifymic(),
which doesn't copy the message, for confidentiality protection
the extra copy is really in the noise of the encryption.

-Martin