blob: c9448008b55ac1532d467e7db824b07dda1e3642 [file] [log] [blame]
Scott Bakered4efab2020-01-13 19:12:25 -08001package types
2
3import (
4 "github.com/jcmturner/gofork/encoding/asn1"
5)
6
7// Reference: https://www.ietf.org/rfc/rfc4120.txt
8// Section: 5.2.6
9
10/*
11AuthorizationData
12
13-- NOTE: AuthorizationData is always used as an OPTIONAL field and
14-- should not be empty.
15AuthorizationData ::= SEQUENCE OF SEQUENCE {
16ad-type [0] Int32,
17ad-data [1] OCTET STRING
18}
19
20ad-data
21This field contains authorization data to be interpreted according
22to the value of the corresponding ad-type field.
23
24ad-type
25 This field specifies the format for the ad-data subfield. All
26negative values are reserved for local use. Non-negative values
27are reserved for registered use.
28
29Each sequence of type and data is referred to as an authorization
30element. Elements MAY be application specific; however, there is a
31common set of recursive elements that should be understood by all
32implementations. These elements contain other elements embedded
33within them, and the interpretation of the encapsulating element
34determines which of the embedded elements must be interpreted, and
35which may be ignored.
36
37These common authorization data elements are recursively defined,
38meaning that the ad-data for these types will itself contain a
39sequence of authorization data whose interpretation is affected by
40the encapsulating element. Depending on the meaning of the
41encapsulating element, the encapsulated elements may be ignored,
42might be interpreted as issued directly by the KDC, or might be
43stored in a separate plaintext part of the ticket. The types of the
44encapsulating elements are specified as part of the Kerberos
45specification because the behavior based on these values should be
46understood across implementations, whereas other elements need only
47be understood by the applications that they affect.
48
49Authorization data elements are considered critical if present in a
50ticket or authenticator. If an unknown authorization data element
51type is received by a server either in an AP-REQ or in a ticket
52contained in an AP-REQ, then, unless it is encapsulated in a known
53authorization data element amending the criticality of the elements
54it contains, authentication MUST fail. Authorization data is
55intended to restrict the use of a ticket. If the service cannot
56determine whether the restriction applies to that service, then a
57security weakness may result if the ticket can be used for that
58service. Authorization elements that are optional can be enclosed in
59an AD-IF-RELEVANT element.
60
61In the definitions that follow, the value of the ad-type for the
62element will be specified as the least significant part of the
63subsection number, and the value of the ad-data will be as shown in
64the ASN.1 structure that follows the subsection heading.
65
66 Contents of ad-data ad-type
67
68 DER encoding of AD-IF-RELEVANT 1
69
70 DER encoding of AD-KDCIssued 4
71
72 DER encoding of AD-AND-OR 5
73
74 DER encoding of AD-MANDATORY-FOR-KDC 8
75
76*/
77
78// AuthorizationData implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6
79type AuthorizationData []AuthorizationDataEntry
80
81// AuthorizationDataEntry implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6
82type AuthorizationDataEntry struct {
83 ADType int32 `asn1:"explicit,tag:0"`
84 ADData []byte `asn1:"explicit,tag:1"`
85}
86
87// ADIfRelevant implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6.1
88type ADIfRelevant AuthorizationData
89
90// ADKDCIssued implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6.2
91type ADKDCIssued struct {
92 ADChecksum Checksum `asn1:"explicit,tag:0"`
93 IRealm string `asn1:"optional,generalstring,explicit,tag:1"`
94 Isname PrincipalName `asn1:"optional,explicit,tag:2"`
95 Elements AuthorizationData `asn1:"explicit,tag:3"`
96}
97
98// ADAndOr implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6.3
99type ADAndOr struct {
100 ConditionCount int32 `asn1:"explicit,tag:0"`
101 Elements AuthorizationData `asn1:"explicit,tag:1"`
102}
103
104// ADMandatoryForKDC implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6.4
105type ADMandatoryForKDC AuthorizationData
106
107// Unmarshal bytes into the ADKDCIssued.
108func (a *ADKDCIssued) Unmarshal(b []byte) error {
109 _, err := asn1.Unmarshal(b, a)
110 return err
111}
112
113// Unmarshal bytes into the AuthorizationData.
114func (a *AuthorizationData) Unmarshal(b []byte) error {
115 _, err := asn1.Unmarshal(b, a)
116 return err
117}
118
119// Unmarshal bytes into the AuthorizationDataEntry.
120func (a *AuthorizationDataEntry) Unmarshal(b []byte) error {
121 _, err := asn1.Unmarshal(b, a)
122 return err
123}