[42] in GSSAPI Development
Re: GSS-level token wrapping
daemon@ATHENA.MIT.EDU (John Linn. 508.486.6588. DTN 226-6)
Wed May 15 09:52:35 1991
Date: Wed, 15 May 91 09:50:44 EDT
From: "John Linn. 508.486.6588. DTN 226-6588. 15-May-1991 0849" <linn@zendia.enet.dec.com>
To: gssapi-dev@ATHENA.MIT.EDU
>1) It seems very strange that the syntax for GSS-API "token" would be
>specified in a document about the Generic Security Services APPLICATION
>PROGRAM INTERFACE. It seems that all of a sudden we are expanding what
>the GSS API is all about, from something which provides compile-time
>interoperability to something which provides run-time interoperability
>accros different implementations of the "GSS API". This may or may not
>be a good idea, but if we really want to do this, you might want to
>change the name GSS API to something which more accurately reflects the
>scope of what you're trying to do.
Run-time interoperability across different GSS-API implementations sharing
support for a common mechanism has always been a goal. Puristically, I
agree that the title "GSS-API" is belied by the inclusion of a small
fragment of protocol specification. Practically, that small fragment of
protocol specification is a matter of interest to any implementor of
GSS-API mechanisms or integrator of GSS-API tokens, and it was included in
the same document in the interests of convenient access to information in
one place. It seemed counterproductive to spin it off into an independent
1-page document which would have to be cross-referenced and separately
distributed, but this debate may be revisited as we evolve the related
document tree within the IETF.
>2) Perhaps it would make sense to demand the use of DER for the tokens.
>It would make it that much easier to write hand-written ASN.1 parsers
>that might have a chance of being small, efficient, and robust.
The intro paragraph which goes with the ASN.1 I distributed currently says
"Use of this format (with ASN.1-encoded data elements represented in BER)
is recommended...". I'm amenable to tightening the recommendation from BER
to X.509-DER, per X.509 clause 8.7 in the interests of simplifying the
parsing space; is anyone opposed?
>3) By including the mechanism OID in the initial context token, are you
>making any statement about how the server and the client will negotiate
>which mechanism to use? If client/server know ahead of time what
>mechanism to use, then including the mechanism type is redundant. If you
>are suggesting that the client/server negotiate which mechanism to use,
>I don't think we have enough implementation experience to know whether
>or not this is a good idea, or how to go about such negotiations. I
>know that Jeff Schiller has expressed grave reservations about whether
>or negotiating authentication mechanisms is at all advisable.
Including the mech_type in the initial token is a declaration facility, and
does not presuppose negotiation. Consider one client which supports only
mechanism A, a second client which supports only mechanism B, and a server
which can accept either A or B tokens. There might be out-of-band knowledge
("that server is able to accept my tokens"), or mechanisms acceptable at a
target might be identified in a DNS-like record, in the manner that
supported protocols are identified today. If there's ever to be a target
system which is capable of accepting tokens of more than one mechanism,
there needs to be a way for that target to disambiguate one token type from
another, and the mech_type tag provides the means for this disambiguation
in a uniform way which protocol integrators don't have to be concerned
with. I believe that Jeff's reservations about negotiation as a concept
relate to concern about including significantly-weaker mechanisms within
the set which a peer is willing to negotiate to, rather than for purposes
of deciding among alternative mechanisms of comparable strength, but assume
he'll correct me if I've misconstrued our discussions on this point.
--jl
