Subject: Questions on RFC2078

From: Fengmin Gong <[email-masked]>
Date: Wed, 21 Jan 1998 12:11:47 -0500

Hi there,

I am planning to use GSS-API and IDUP-GSS-API in a DARPA
project.  The gist of the project is to create a GSS-API
/IDUP-GSS-API mechanisms implementation which actually
utilizes other security mechansims (ATM cell encryptor,
IPSEC, crypto accellerator etc) to satisfy certain security
service needs of network applications.  Those security
mechanisms are typically distributed among different protocol
layers or across the network.  We want to be able to
utilize them in a dynamic fashion.

Ok, here are my specific questions/suggestions regarding
the GSS-API V2 as specified by RFC2078.  I may be ignorant
of any new development in the CAT group on GSS-API.  I will
appreciate very much the feedback from the active developers
of the spec.  I have sent my subscription to 
[email-masked], but please copy me specifically
in your reply just to be sure.

1) RFC2078 does not inlcude any input parameters for indicating
applications' desire regarding the services or QoP in the
context initilization call.  Those parameters are deferred to
the per-message calls.  It seems reasonable to expect the
applications to have some idea of what they would like to do
with the context when they try to establish one.  In my
project scenario, most of the setup and coordination would
take place at context establishment time but I do not have
those important information to go with.  I have found out that
IDUP-GSS-API draft (dated March 25, 1997) does include such
parameters for the environment establishment call, shouldn't
GSS-API do the same?  It should be pointed out that having
the similar parameters at the per-message level is still a
good idea and should be kept there.

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.

Thanks for your attention,
Fengmin

--
Fengmin Gong, D.Sc.			E-mail: [email-masked]
Manager, Advanced Networking Research	Phone:  919 248-9214
MCNC, P.O.Box 12889			FAX:    919 248-1455
3021 Cornwallis Rd., RTP, NC 27709	WWW:	http://www.mcnc.org

---

From: "Linn, John" <[email-masked]>
Date: Wed, 21 Jan 1998 16:15:32 -0500

> good idea and should be kept there.
The current working draft successor to rfc2078
(draft-ietf-cat-rfc2078bis-01.txt) adds conf_req_flag and integ_req_flag
inputs to gss_init_sec_context().  These service request indicators,
unlike QOP values, can be provided in a mechanism-independent fashion
and (given that bindings represent the flags as bits within an already
existing word) were possible to add in a backward-compatible fashion.
QOP requests would be mechanism-specific and would require
less-compatible changes to the call signature. 

> separate per-message calls avoid changing any of the
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?

> Thanks for your attention,
--jl