BER.
-- optional top-level token definitions to
-- frame different mechanisms
GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- data structure definitions
-- callers must be able to distinguish among
-- InitialContextToken, SubsequentContextToken,
-- PerMsgToken, and SealedMessage data elements
-- based on the usage in which they occur
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 or not encrypted
sealedUserData ANY
END
APPENDIX C
MECHANISM DESIGN CONSTRAINTS
The following constraints on GSS-API mechanism designs are adopted in
response to observed caller protocol requirements, and adherence
thereto is anticipated in subsequent descriptions of GSS-API
mechanisms to be documented in standards-track Internet
specifications.
Use of the approach defined in Appendix B of this specification,
applying a mechanism type tag to the InitialContextToken, is
required.
It is strongly recommended that mechanisms offering per-message
protection services also offer at least one of the replay detection
and sequencing services, as mechanisms offering neither of the latter
will fail to satisfy recognized requirements of certain candidate
caller protocols.