[40] in GSSAPI Development
Re: GSS-level token wrapping
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue May 14 12:10:40 1991
Date: Tue, 14 May 91 12:07:42 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: "John Linn. 508.486.6588. DTN 226-6588. 03-May-1991 0845"
Cc: gssapi-dev@ATHENA.MIT.EDU
In-Reply-To: [36]
Reply-To: tytso@ATHENA.MIT.EDU
Hmm... I just noticed that there's been no discussion on the "wrapper"
syntax for the GSS-API tokens. I do have a couple of comments on it:
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.
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.
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.
4) The GSS API that is released with the Beta 1 release of Kerberos V5
will not support your proposed standard. I simply do not have the time
to convert our implementation over to use ASN.1. I have talked to Jeff
about this, and he agrees with me that it is not worth pushing back the
Beta release of Kerberos just for this change. As for later releases
--- we'll see.
- Ted
P.S. Just for haha's allow me to share with you the current token
format which I have implemented. Note that it is small, clean, and
compact, and parsing these tokens is consequently simple and
straightforward:
/*
* Token format:
*
* Byte 0: GSS API Implementation Version (currently 1)
* Byte 1: Mechanism Identifier (currently 1 means Kerberos V5)
* Byte 2: Token type (mechanism specific)
* Byte 3: Reserved
* Byte 4--n: Mechanism/Token information
*/
#define GSS_API_IMPL_VERSION 1
#define GSS_API_KRB5_TYPE 1
/* Token types */
#define GSS_API_KRB5_REQ 1
#define GSS_API_KRB5_REP 2
#define GSS_API_KRB5_SAFE 3
#define GSS_API_KRB5_PRIV 4
#define GSS_API_KRB5_ERROR 5
#define GSS_API_KRB5_SHUTDOWN 31
