[36] in GSSAPI Development
GSS-level token wrapping
daemon@ATHENA.MIT.EDU (John Linn. 508.486.6588. DTN 226-6)
Sat May 4 05:52:36 1991
Date: Sat, 4 May 91 02:51:44 PDT
From: "John Linn. 508.486.6588. DTN 226-6588. 03-May-1991 0845" <linn@zendia.enet.dec.com>
To: gssapi-dev@ATHENA.MIT.EDU
Appendix B of GSS-API C.3 proposed a recommended mechanism-independent
"wrapper" syntax for GSS-API tokens. We're planning to follow the example
set by SPX and described by the attached ASN.1, which is a simplification
of the syntax proposed in C.3. In particular, this simplification
includes ASN.1 typing and a mechanism type identifier for only the initial
token in the context establishment process; once passed in the initial
token, both peers know the mechanism type against which subsequent tokens
on that context should be processed. (If MIT needs an OID assigned
quickly to identify the Kerberos GSS-API mechanism, we can provide one
under our subtree.) In submitting the base GSS-API spec as an
Internet-Draft, I'd like to replace the syntax proposal with this
simplified version. Can we all agree on this as a common approach for
tagging initial context tokens for mechanism type identification purposes,
in the interests of interoperability?
--jl
GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- data structure definitions
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
}
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
PerMsgToken ::=
-- as emitted by GSS_Sign and processed by GSS_Verify
innerMsgToken ANY
SealedMessage ::=
-- as emitted by GSS_Seal and processed by GSS_Unseal
-- includes internal, mechanism-defined indicator of whether encrypted
sealedUserData ANY
END
