Determining a token's mechanism

[John Linn <[e-mail]>]

Dan Nessett writes, excerpting:

>As far as I can tell, there
>is no other gssapi routine that will take the input_token and return
>the mech_type, so there is no way for the "glue layer" routine to find out
>which underlying routine to call.
>
>One possible solution is to enhance gss_process_context_token() so that it
>can accept an input_token and return its mech_type. Another is to create
>yet another gssapi function, say, gss_token_mech_type(), that does this.
>While I like neither of these options, I don't see any other way around this.
>If someone has a better idea, I would welcome it.

Note that mech_type determination is one of the outputs of
SPKM_Parse_token(), as described in draft-ietf-cat-spkmgss-02.txt and
discussed at the Danvers meeting, where some interest was evident in
considering this function as a GSS-level routine.

As a result of that discussion, 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, 7 April:

>The gss_parse_token() routine would be easy to implement, and it would
>do the right thing for all krb5 tokens.

Dennis Glatting, 7 April:

>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, 10 April:

>(2) 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.

On 24 April, Dennis wrote, in reply to Dan's message above:

>I made the packaging of the GSS token header in the glue
>code. When a token is received the glue code separates the
>token's components yielding length (handy for a sanity
>check), mechanism OID, and mechanism token. Thus the
>token interface between the glue layer and the mechanism
>is the mechanism's token component.  

and, in a subsequent message:

>Would not an enhanced gss_process_context_token()
>function need to be located in the glue code? 

It appears to me that we already have one active proposal
(SPKM_Parse_token()) on the virtual table which 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 believe, therefore,
that we should focus discussion on this proposal rather than on 
alternatives which provide specific subsets of its capabilities. 
Based on the discussion summarized above, responding implementors
have indicated that it would be feasible within their code bases
to provide at least some of the outputs of SPKM_Parse_token(); within
the structure of a multi-mechanism GSS-API implementation, I'd expect
that at least a part of that routine's functions would be performed
within an upper, mechanism-independent sublayer.  

The key question now at hand, I believe, is whether inclusion of
SPKM_Parse_token(), or a variant thereof, within GSS-V2 would offer
motivating value, given an understanding that not all of its return
values can be available in all cases from all implementations.
Discussion hereby solicited.

--jl