Towards closure re GSS_Parse_token()

[John Linn <[e-mail]>]

CAT fanciers:

In the interest of progress and parallelism as other discussions
proceed, I'd like to reach closure on the question of whether or not
to include within the GSS-V2 spec a GSS_Parse_token() routine, based
on or derived from SPKM_Parse_token().  It doesn't appear that our
discussions on this issue have converged.  We appear agreed that not
all of SPKM_Parse_token()'s attribute outputs (mechanism type, token
type, and associated context handle) can be provided in all
circumstances and by all mechanisms, but remain divergent as to the
utility of such a routine to application writers despite this fact.
It doesn't appear to me, therefore, that consensus to include this
facility within GSS-V2 has been achieved; unless further discussion
ensues in response to this message, my working assumption is that
we're not currently pursuing standardization of
GSS_Parse_token(). Mechanism implementors able and interested in
incorporating such a function may, of course, do so as an additional
feature alongside their GSS-API libraries.

For reference, the remainder of this message reviews the bidding on
this topic.  As a result of discussion at Danvers, I sent out an
implementor's poll query on 7 April to the list, with the following
relevant paragraph:

>(2) Referring to the SPKM_Parse_token() routine as described in
>draft-ietf-cat-spkmgss-02.txt, we would like to consider the
>feasibility of incorporating an equivalent routine within GSS-V2.
>Question to implementors: please review the definition of this routine
>and consider whether its functionality is implementable within your
>mechanism and code base.

The following replies were received on this point:

Marc Horowitz: "The gss_parse_token() routine would be easy to
implement, and it would do the right thing for all krb5 tokens."  Marc
subsequently clarified (25 April), however: "I don't believe that
SPKM_Parse_token() is a useful function in light of its inherent
nonportability, and I'd rather not see it included in the spec."

Dennis Glatting: "My vote: Do not include a derivitive of
SPKM_Parse_token() in V2.  Unless there is a requirement to encode an
OID in all tokens then the usefulness of a SPKM_Parse_token()
derivative in GSSAPI-V2 is dubious."

John Wray: "We do include the GSS wrapper on every token; we don't
send any context identifier along with a token.  So from a token we
can identify the mechanism and the token-type, but not the context to
which it belongs.  Therefore we can provide some but not all of
gss_parse_token's functionality."

Following some exchanges about extending gss_process_context_token()
to return descriptive attributes about a token, I observed that the
SPKM_Parse_token() proposal provides a general approach to the
question of determining attributes of a token, also covering other
attributes besides mechanism type and equally suited to context
management and per-message tokens.  I suggested, therefore, that we
should focus discussion on this proposal rather than on alternatives
which provide specific subsets of its capabilities, and further
indicated an expectation that at least a part of that routine's
functions would be performed within an upper, mechanism-independent
sublayer.

Dan Nessett replied (25 April): "I would strongly support the
inclusion of a gss_parse_token() that returns the mech_type of an
InitialContextToken. If it returns other information, that's OK too,
but I don't see a way to write the mechanism independent glue layer
without something that does the former."

Dennis Glatting commented (25 April), regarding the value of
parse_token():

"That section [draft-ietf-cat-spkmgss-02.txt, sec. 6] assumes all
tokens are encoded with an OID and a token type identifier. The
GSS-API does not make that a requirement thereby making the
SPKM_Parse_token()'s utility as a general purpose GSS-API function
dubious. Further, SPKM_Parse_token()'s function is to aid
demultiplexing tokens which is only useful in a limited context.

The function SPKM_Parse_token() is useful if you have a single context
for a given mechanism and are blindly exchanging tokens after a
context is established.  However, many application protocols know what
is being exchanged and how to process the data thereby mitigating the
need to interrogate GSS-API tokens. Further, those application
protocols may have to encapsulate GSS-API tokens to indicate
length. Why not a type indicator too?

When we look away from mechanism exclusivity and tokens sent blindly
across a connection to multiple mechanism contexts across one or more
connections then the utility of SPKM_Parse_token() is lost.

For these reasons I do not believe a GSS-API variant of
SPKM_Parse_token() is useful to the application programmer. My
questions stand."

Doug Rosenthal commented (27 April): 

"Not to belabor the issue, but given that the token parsing
functionality is either put in a separate function (aka parse_token)
or done "manually" in a multi-mech glue layer, the former would be
more convenient - as it could be used/called by either a multi-mech
glue layer or a single-mech application (if necessary).  Doesn't seem
like a hard function to implement, and would give application
developers another utility function if they needed it.

Also, is it really non-portable if some implementations simply return
null for some of the function outputs while other implementations
return non-null values?  Isn't this the case for some of the other GSS
functions anyway, depending on the underlying
mechansim/implementation?  (e.g. the _state values returned from
init/accept_sec_context)"

--jl