idnits 2.17.1 draft-brezak-win2k-krb-authz-01.txt: ** The Abstract section seems to be numbered -(177): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 12 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 303 looks like a reference -- Missing reference section? '2' on line 146 looks like a reference -- Missing reference section? '4' on line 142 looks like a reference -- Missing reference section? '7' on line 148 looks like a reference -- Missing reference section? '6' on line 256 looks like a reference -- Missing reference section? '0' on line 343 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos working group John Brezak 3 Internet Draft Microsoft 4 Document: draft-brezak-win2k-krb-authz-01.txt 5 Category: Informational October, 2002 7 Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for 8 Access Control to Resources 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026 [1] except that the right to create 14 derivative works is not granted. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. Internet-Drafts are draft 18 documents valid for a maximum of six months and may be updated, 19 replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet- Drafts as reference material or to 21 cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 1. Abstract 31 Microsoft Windows 2000 includes operating system specific data in 32 the Kerberos V5 [1] authorization data field that is used for access 33 control. This data is used to create an NT access token. The access 34 token is used by the system to enforce access checking when 35 attempting to access objects. This document describes the structure 36 of the Windows 2000 specific authorization data that is carried in 37 that field for use by servers in performing access control. 39 2. Conventions used in this document 41 All defined data structures are defined using "C" style constructs 42 unless otherwise stated. All data is encoded as little-endian. 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC-2119 [2]. 48 3. Top-Level PAC Structure 50 The PAC is generated by the KDC under the following conditions: 52 Windows 2000 Kerberos Authorization Data October 2002 54 o during an AS request that has been validated with pre- 55 authentication 56 o during a TGS request when the client has no PAC and the target 57 is a service in the domain or a ticket granting service 58 (referral ticket). 60 The PAC itself is included in the IF-RELEVANT (ID 1) portion of the 61 authorization data in a ticket. Within the IF-RELEVANT portion, it 62 is encoded KERB_AUTH_DATA_PAC with ID 128. 64 The PAC is defined as a C data type, with integers encoded in 65 little-endian order. The PAC itself is made up of several layers. 66 The outer structure, contained directly in the authorization data, 67 is as follows. The top-level structure is the PACTYPE structure: 69 typedef unsigned long ULONG; 70 typedef unsigned short USHORT; 71 typedef unsigned long64 ULONG64; 72 typedef unsigned char UCHAR; 74 typedef struct _PACTYPE { 75 ULONG cBuffers; 76 ULONG Version; 77 PAC_INFO_BUFFER Buffers[1]; 78 } PACTYPE; 80 The fields are defined as follows: 81 cBuffers - contains the number of entries in the array Buffers 82 Version - this is version zero 83 Buffers - contains a conformant array of PAC_INFO_BUFFER structures 85 The PAC_INFO_BUFFER structure contains information about each piece 86 of the PAC. 88 typedef struct _PAC_INFO_BUFFER { 89 ULONG ulType; 90 ULONG cbBufferSize; 91 ULONG64 Offset; 92 } PAC_INFO_BUFFER; 94 Type fields are defined as follows: 96 ulType - contains the type of data contained in this buffer. For 97 Windows 2000 access control, it may be one of the following, 98 which are explained further below: 100 #define PAC_LOGON_INFO 1 101 #define PAC_SERVER_CHECKSUM 6 102 #define PAC_PRIVSVR_CHECKSUM 7 104 Offset - contains the offset to the beginning of the data, in bytes, 105 from the beginning of the PACTYPE structure. The data offset 106 must by a multiple of 8. If the data pointed to by this 107 Windows 2000 Kerberos Authorization Data October 2002 109 field is complex, the data is typically NDR encoded. If the 110 data is simple (indicating it includes no pointer types or 111 complex structures) it is a little-endian format data 112 structure. 114 4. PAC Credential Information (PAC_LOGON_INFO) 116 PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential 117 information for the client of the Kerberos ticket. The data itself 118 is contained in a KERB_VALIDATION_INFO structure, which is NDR 119 encoded. The output of the NDR encoding is placed in the 120 PAC_INFO_BUFFER structure of type PAC_LOGON_INFO. 122 typedef struct _KERB_VALIDATION_INFO { 123 FILETIME Reserved0; 124 FILETIME Reserved1; 125 FILETIME KickOffTime; 126 FILETIME Reserved2; 127 FILETIME Reserved3; 128 FILETIME Reserved4; 129 UNICODE_STRING Reserved5; 130 UNICODE_STRING Reserved6; 131 UNICODE_STRING Reserved7; 132 UNICODE_STRING Reserved8; 133 UNICODE_STRING Reserved9; 134 UNICODE_STRING Reserved10; 135 USHORT Reserved11; 136 USHORT Reserved12; 137 ULONG UserId; 138 ULONG PrimaryGroupId; 139 ULONG GroupCount; 140 [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds; 141 ULONG UserFlags; 142 ULONG Reserved13[4]; 143 UNICODE_STRING Reserved14; 144 UNICODE_STRING Reserved15; 145 PSID LogonDomainId; 146 ULONG Reserved16[2]; 147 ULONG Reserved17; 148 ULONG Reserved18[7]; 149 ULONG SidCount; 150 [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids; 151 PSID ResourceGroupDomainSid; 152 ULONG ResourceGroupCount; 153 [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP 154 ResourceGroupIds; 155 } KERB_VALIDATION_INFO; 157 Reserved fields are not defined in this document and are not used in 158 the construction of access control tokens. 160 The fields are defined as follows: 162 Windows 2000 Kerberos Authorization Data October 2002 164 KickOffTime - the time at which the server should forcibly logoff 165 the client. If the client should not be forced off, this 166 field should be set to (0x7fffffff,0xffffffff). If a kickoff 167 time is to be enforced, the service ticket lifetime will 168 never exceed this value. 169 UserId - This field contains the relative Id for the client. If 170 zero, then the User ID is the first SID in the ExtraSids 171 field. 172 PrimaryGroupId - This field contains the relative ID for this 173 client�s primary group. 174 GroupCount - This field contains the number of groups, within the 175 client�s domain, to which the client is a member. 176 GroupIds - This field contains an array of the relative Ids and 177 attributes of the groups in the client�s domain of which the 178 client is a member. 179 UserFlags - This field contains information about which fields in 180 this structure are valid. The two bits that may be set are 181 indicated below. Having these flags set indicates that the 182 corresponding fields in the KERB_VALIDATION_INFO structure 183 are present and valid. 185 #define LOGON_EXTRA_SIDS 0x0020 186 #define LOGON_RESOURCE_GROUPS 0x0200 188 LogonDomainId - This field contains the SID of the client�s domain. 189 This field is used in conjunction with the UserId, 190 PrimaryGroupId,and GroupIds fields to create the user and 191 group SIDs for the client. 192 SidCount - This field contains the number of SIDs present in the 193 ExtraSids field. This field is only valid if the 194 LOGON_EXTRA_SIDS flag has been set in the UserFlags field. 195 ExtraSids - This field contains a list of SIDs for groups to which 196 the user is a member. This field is only valid if the 197 LOGON_EXTRA_SIDS flag has been set in the UserFlags field. 198 ResouceGroupCount - This field contains the number of resource 199 groups in the ResourceGroupIds field. This field is only 200 valid if the LOGON RESOURCE_GROUPS flag has been set in the 201 UserFlags field._ 202 ResourceGroupDomainSid - This field contains the SID of the resource 203 domain. This field is used in conjunction with the 204 ResourceGroupIds field to create the group SIDs for the 205 client. 206 ResourceGroupIds - This field contains an array of the relative Ids 207 and attributes of the groups in the resource domain of which 208 the resource is a member. 210 When used in the KERB_VALIDATION_INFO, this is NDR encoded. The 211 FILETIME type is defined as follows: 213 typedef unsigned int DWORD; 215 typedef struct _FILETIME { 216 DWORD dwLowDateTime; 217 Windows 2000 Kerberos Authorization Data October 2002 219 DWORD dwHighDateTime; 220 } FILETIME; 222 Times are encoded as the number of 100 nanosecond increments since 223 January 1, 1601, in UTC time. 225 When used in the KERB_VALIDATION_INFO, this is NDR encoded. The 226 UNICODE_STRING structure is defined as: 228 typedef struct _UNICODE_STRING 229 USHORT Length; 230 USHORT MaximumLength; 231 [size_is(MaximumLength / 2), length_is((Length) / 2) ] 232 USHORT * Buffer; 233 } UNICODE_STRING; 235 The Length field contains the number of bytes in the string, not 236 including the null terminator, and the MaximumLength field contains 237 the total number of bytes in the buffer containing the string. 239 The GROUP_MEMBERSHIP structure contains the relative ID of a group 240 and the corresponding attributes for the group. 242 typedef struct _GROUP_MEMBERSHIP { 243 ULONG RelativeId; 244 ULONG Attributes; 245 } *PGROUP_MEMBERSHIP; 247 The group attributes must be: 249 #define SE_GROUP_MANDATORY (0x00000001L) 250 #define SE_GROUP_ENABLED_BY_DEFAULT (0x00000002L) 251 #define SE_GROUP_ENABLED (0x00000004L) 253 The SID structure is defined as follows: 255 typedef struct _SID_IDENTIFIER_AUTHORITY { 256 UCHAR Value[6]; 257 } SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY; 259 The constant value for the NT Authority is 261 #define SECURITY_NT_AUTHORITY {0,0,0,0,0,5} 263 typedef struct _SID { 264 UCHAR Revision; 265 UCHAR SubAuthorityCount; 266 SID_IDENTIFIER_AUTHORITY IdentifierAuthority; 267 [size_is(SubAuthorityCount)] ULONG SubAuthority[*]; 268 } SID, *PSID; 269 Windows 2000 Kerberos Authorization Data October 2002 271 Other authorities are defined in the Microsoft Developer Network 272 Development Kit 3. 273 The SubAuthorityCount field contains the number of elements in the 274 actual SubAuthority conformant array. The maximum number of 275 subauthorities allowed is 15. 277 The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and 278 their corresponding attributes: 280 typedef struct _KERB_SID_AND_ATTRIBUTES { 281 PSID Sid; 282 ULONG Attributes; 283 } KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES; 285 The attributes are the same as the group attributes defined above. 287 5. Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM) 289 The PAC contains two digital signatures: one using the key of the 290 server, and one using the key of the KDC. The signatures are present 291 for two reasons. First, the signature with the server�s key is 292 present to prevent a client from generating their own PAC and 293 sending it to the KDC as encrypted authorization data to be included 294 in tickets. Second, the signature with the KDC�s key is present to 295 prevent an untrusted service from forging a ticket to itself with an 296 invalid PAC. The two signatures are sent in PAC_INFO_BUFFERs of type 297 PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM respectively. 299 The signatures are contained in the following structure: 301 typedef struct _PAC_SIGNATURE_DATA { 302 ULONG SignatureType; 303 UCHAR Signature[1]; 304 } PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA; 306 The fields are defined as follows: 308 SignatureType - This field contains the type of checksum used to 309 create a signature. The checksum must be a keyed checksum. 311 Signature - This field consists of an array of bytes containing the 312 checksum data. The length of bytes may be determined by the 313 wrapping PAC_INFO_BUFFER structure. 315 For the server�s checksum, the key used to generate the signature 316 should be the same key used to encrypt the ticket. Thus, if the 317 enc_tkt_in_skey option is used, the session key from the server�s 318 TGT should be used. The Key used to encrypt ticket granting tickets 319 is used to generate the KDC�s checksum. 321 The checksums are computed as follows: 323 Windows 2000 Kerberos Authorization Data October 2002 325 1. The complete PAC is built, including space for both checksums 326 2. The data portion of both checksums is zeroed. 327 3. The entire PAC structure is checksummed with the server�s key, 328 and the result is stored in the server�s checksum structure. 329 4. The server�s checksum is then checksummed with the KDC's key. 330 5. The checksum with the KDC key is stored in the KDC's checksum 331 structure. 333 6. PAC Request Pre-Auth Data 335 Normally, the PAC is included in every pre-authenticated ticket 336 received from an AS request. However, a client may also explicitly 337 request either to include or to not include the PAC. This is done by 338 sending the PAC-REQUEST preauth data. 340 This is an ASN.1 encoded structure. 342 KERB-PA-PAC-REQUEST ::= SEQUENCE { 343 include-pac[0] BOOLEAN -- if TRUE, and no pac present, 344 -- include PAC. 345 ---If FALSE, and pac 346 -- PAC present, remove PAC 347 } 349 The fields are defined as follows: 351 include-pac - This field indicates whether a PAC should be included 352 or not. If the value is TRUE, a PAC will be included 353 independent of other preauth data. If the value is FALSE, 354 then no PAC will be included, even if other preauth data is 355 present. 357 The preauth ID is: 358 #define KRB5_PADATA_PAC_REQUEST 128 360 7. Security Considerations 362 Before the PAC data is used for access control, the 363 PAC_SERVER_CHECKSUM signature MUST be checked. This will verify that 364 the provider of the PAC data knows the server's secret key. 365 Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to 366 verify that the PAC was issued from the KDC and not placed in the 367 ticket by someone other than the KDC with access to the service key. 369 Caution must be used with accepting the SIDs present in the logon- 370 info part of the PAC. Only SIDs from a domain that is authoritative 371 for a particular domain's SIDs should be used in the construction of 372 access tokens. If a SID is found to be from outside of a domain's 373 authoritative SID namespace, it MUST be ignored for purposes of 374 access control. 376 8. References 377 Windows 2000 Kerberos Authorization Data October 2002 379 1 Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 380 (V5)", RFC 1510, September 1993 382 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 383 Levels", BCP 14, RFC 2119, March 1997 385 3 Microsoft Developer's Network - http://msdn.microsoft.com 387 9. Author's Addresses 389 John Brezak 390 Microsoft Corporation 391 One Microsoft Way 392 Redmond, Washington 393 Email: jbrezak@microsoft.com 394 Windows 2000 Kerberos Authorization Data October 2002 396 Full Copyright Statement 398 Copyright (C) The Internet Society (1999). All Rights Reserved. 400 This document and translations of it may be copied and furnished to 401 others, and derivative works that comment on or otherwise explain it 402 or assist in its implementation may be prepared, copied, published 403 and distributed, in whole or in part, without restriction of any 404 kind, provided that the above copyright notice and this paragraph 405 are included on all such copies and derivative works. However, this 406 document itself may not be modified in any way, such as by removing 407 the copyright notice or references to the Internet Society or other 408 Internet organizations, except as needed for the purpose of 409 developing Internet standards in which case the procedures for 410 copyrights defined in the Internet Standards process must be 411 followed, or as required to translate it into languages other than 412 English. 414 The limited permissions granted above are perpetual and will not be 415 revoked by the Internet Society or its successors or assigns. 417 This document and the information contained herein is provided on an 418 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 419 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 420 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 421 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 422 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."