1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
Spnego {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) snego(2)}
-- (1.3.6.1.5.5.2)
DEFINITIONS ::=
BEGIN
MechType::= OBJECT IDENTIFIER
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenTarg [1] NegTokenTarg }
MechTypeList ::= SEQUENCE OF MechType
--
-- MS-SPNG tells us that the format of a negTokenInit is actually
-- negTokenInit2 if a negTokenInit is seen in a response. It might need
-- to be the first negTokenInit seen in a response, but I am not sure.
-- It will only occur in a NegotiateProtocol response in CIFS/SMB or SMB2.
--
NegTokenInit ::= SEQUENCE {
mechTypes [0] MechTypeList OPTIONAL,
reqFlags [1] ContextFlags OPTIONAL,
mechToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL
}
NegHints ::= SEQUENCE {
hintName [0] GeneralString OPTIONAL,
hintAddress [1] OCTET STRING OPTIONAL
}
NegTokenInit2 ::= SEQUENCE {
mechTypes [0] MechTypeList OPTIONAL,
reqFlags [1] ContextFlags OPTIONAL,
mechToken [2] OCTET STRING OPTIONAL,
negHints [3] NegHints OPTIONAL,
mechListMIC [4] OCTET STRING OPTIONAL
}
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
confFlag (5),
integFlag (6)
}
NegTokenTarg ::= SEQUENCE {
negResult [0] ENUMERATED {
accept-completed (0),
accept-incomplete (1),
reject (2) } OPTIONAL,
supportedMech [1] MechType OPTIONAL,
responseToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL
}
--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 InnerContextToken
-- DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
-- SubsequentContextToken ::= InnerContextToken
InnerContextToken ::= ANY
-- interpretation based on predecessor InitialContextToken
-- ASN.1 structure not required
-- PerMsgToken ::=
-- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-- ASN.1 structure not required
-- InnerMsgToken
-- InnerMsgToken ::= ANY
-- SealedMessage ::=
-- as emitted by GSS_Wrap and processed by GSS_Unwrap
-- includes internal, mechanism-defined indicator
-- of whether or not encrypted
-- ASN.1 structure not required
-- SealedUserData
-- SealedUserData ::= ANY
-- END GSS-API DEFINITIONS
-- https://datatracker.ietf.org/doc/html/draft-ietf-kitten-iakerb-03#section-3
--
-- Note that MIT Kerberos encodes target-realm as OCTET STRING
--
IAKERB-HEADER ::= SEQUENCE {
-- Note that the tag numbers start at 1, not 0, which would
-- be more conventional for Kerberos.
target-realm [1] UTF8String,
-- The name of the target realm.
cookie [2] OCTET STRING OPTIONAL,
-- Opaque data, if sent by the server,
-- MUST be copied by the client verbatim into
-- the next IAKRB_PROXY message.
...
}
END
|
