diff options
Diffstat (limited to 'doc/standardisation/draft-brezak-win2k-krb-authz-01.txt')
| -rw-r--r-- | doc/standardisation/draft-brezak-win2k-krb-authz-01.txt | 523 |
1 files changed, 0 insertions, 523 deletions
diff --git a/doc/standardisation/draft-brezak-win2k-krb-authz-01.txt b/doc/standardisation/draft-brezak-win2k-krb-authz-01.txt deleted file mode 100644 index 172776118..000000000 --- a/doc/standardisation/draft-brezak-win2k-krb-authz-01.txt +++ /dev/null @@ -1,523 +0,0 @@ - - - -Kerberos working group John Brezak -Internet Draft Microsoft -Document: draft-brezak-win2k-krb-authz-01.txt -Category: Informational October, 2002 - - - Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for - Access Control to Resources - - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026 [1] except that the right to create - derivative works is not granted. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. Internet-Drafts are draft - documents valid for a maximum of six months and may be updated, - replaced, or obsoleted by other documents at any time. It is - inappropriate to use Internet- Drafts as reference material or to - cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -1. Abstract - - Microsoft Windows 2000 includes operating system specific data in - the Kerberos V5 [1] authorization data field that is used for access - control. This data is used to create an NT access token. The access - token is used by the system to enforce access checking when - attempting to access objects. This document describes the structure - of the Windows 2000 specific authorization data that is carried in - that field for use by servers in performing access control. - - -2. Conventions used in this document - - All defined data structures are defined using "C" style constructs - unless otherwise stated. All data is encoded as little-endian. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in - this document are to be interpreted as described in RFC-2119 [2]. - - -3. Top-Level PAC Structure - - The PAC is generated by the KDC under the following conditions: - - -Brezak Category - Informational 1 - Windows 2000 Kerberos Authorization Data October 2002 - - - o during an AS request that has been validated with pre- - authentication - o during a TGS request when the client has no PAC and the target - is a service in the domain or a ticket granting service - (referral ticket). - - The PAC itself is included in the IF-RELEVANT (ID 1) portion of the - authorization data in a ticket. Within the IF-RELEVANT portion, it - is encoded KERB_AUTH_DATA_PAC with ID 128. - - The PAC is defined as a C data type, with integers encoded in - little-endian order. The PAC itself is made up of several layers. - The outer structure, contained directly in the authorization data, - is as follows. The top-level structure is the PACTYPE structure: - - typedef unsigned long ULONG; - typedef unsigned short USHORT; - typedef unsigned long64 ULONG64; - typedef unsigned char UCHAR; - - typedef struct _PACTYPE { - ULONG cBuffers; - ULONG Version; - PAC_INFO_BUFFER Buffers[1]; - } PACTYPE; - - The fields are defined as follows: - cBuffers - contains the number of entries in the array Buffers - Version - this is version zero - Buffers - contains a conformant array of PAC_INFO_BUFFER structures - - The PAC_INFO_BUFFER structure contains information about each piece - of the PAC. - - typedef struct _PAC_INFO_BUFFER { - ULONG ulType; - ULONG cbBufferSize; - ULONG64 Offset; - } PAC_INFO_BUFFER; - - Type fields are defined as follows: - - ulType - contains the type of data contained in this buffer. For - Windows 2000 access control, it may be one of the following, - which are explained further below: - - #define PAC_LOGON_INFO 1 - #define PAC_SERVER_CHECKSUM 6 - #define PAC_PRIVSVR_CHECKSUM 7 - - Offset - contains the offset to the beginning of the data, in bytes, - from the beginning of the PACTYPE structure. The data offset - must by a multiple of 8. If the data pointed to by this - -Brezak Category - Informational 2 - Windows 2000 Kerberos Authorization Data October 2002 - - - field is complex, the data is typically NDR encoded. If the - data is simple (indicating it includes no pointer types or - complex structures) it is a little-endian format data - structure. - -4. PAC Credential Information (PAC_LOGON_INFO) - - PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential - information for the client of the Kerberos ticket. The data itself - is contained in a KERB_VALIDATION_INFO structure, which is NDR - encoded. The output of the NDR encoding is placed in the - PAC_INFO_BUFFER structure of type PAC_LOGON_INFO. - - typedef struct _KERB_VALIDATION_INFO { - FILETIME Reserved0; - FILETIME Reserved1; - FILETIME KickOffTime; - FILETIME Reserved2; - FILETIME Reserved3; - FILETIME Reserved4; - UNICODE_STRING Reserved5; - UNICODE_STRING Reserved6; - UNICODE_STRING Reserved7; - UNICODE_STRING Reserved8; - UNICODE_STRING Reserved9; - UNICODE_STRING Reserved10; - USHORT Reserved11; - USHORT Reserved12; - ULONG UserId; - ULONG PrimaryGroupId; - ULONG GroupCount; - [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds; - ULONG UserFlags; - ULONG Reserved13[4]; - UNICODE_STRING Reserved14; - UNICODE_STRING Reserved15; - PSID LogonDomainId; - ULONG Reserved16[2]; - ULONG Reserved17; - ULONG Reserved18[7]; - ULONG SidCount; - [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids; - PSID ResourceGroupDomainSid; - ULONG ResourceGroupCount; - [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP - ResourceGroupIds; - } KERB_VALIDATION_INFO; - - Reserved fields are not defined in this document and are not used in - the construction of access control tokens. - - The fields are defined as follows: - - -Brezak Category - Informational 3 - Windows 2000 Kerberos Authorization Data October 2002 - - - KickOffTime - the time at which the server should forcibly logoff - the client. If the client should not be forced off, this - field should be set to (0x7fffffff,0xffffffff). If a kickoff - time is to be enforced, the service ticket lifetime will - never exceed this value. - UserId - This field contains the relative Id for the client. If - zero, then the User ID is the first SID in the ExtraSids - field. - PrimaryGroupId - This field contains the relative ID for this - clientÆs primary group. - GroupCount - This field contains the number of groups, within the - clientÆs domain, to which the client is a member. - GroupIds - This field contains an array of the relative Ids and - attributes of the groups in the clientÆs domain of which the - client is a member. - UserFlags - This field contains information about which fields in - this structure are valid. The two bits that may be set are - indicated below. Having these flags set indicates that the - corresponding fields in the KERB_VALIDATION_INFO structure - are present and valid. - - #define LOGON_EXTRA_SIDS 0x0020 - #define LOGON_RESOURCE_GROUPS 0x0200 - - LogonDomainId - This field contains the SID of the clientÆs domain. - This field is used in conjunction with the UserId, - PrimaryGroupId,and GroupIds fields to create the user and - group SIDs for the client. - SidCount - This field contains the number of SIDs present in the - ExtraSids field. This field is only valid if the - LOGON_EXTRA_SIDS flag has been set in the UserFlags field. - ExtraSids - This field contains a list of SIDs for groups to which - the user is a member. This field is only valid if the - LOGON_EXTRA_SIDS flag has been set in the UserFlags field. - ResouceGroupCount - This field contains the number of resource - groups in the ResourceGroupIds field. This field is only - valid if the LOGON RESOURCE_GROUPS flag has been set in the - UserFlags field._ - ResourceGroupDomainSid - This field contains the SID of the resource - domain. This field is used in conjunction with the - ResourceGroupIds field to create the group SIDs for the - client. - ResourceGroupIds - This field contains an array of the relative Ids - and attributes of the groups in the resource domain of which - the resource is a member. - - When used in the KERB_VALIDATION_INFO, this is NDR encoded. The - FILETIME type is defined as follows: - - typedef unsigned int DWORD; - - typedef struct _FILETIME { - DWORD dwLowDateTime; - -Brezak Category - Informational 4 - Windows 2000 Kerberos Authorization Data October 2002 - - - DWORD dwHighDateTime; - } FILETIME; - - Times are encoded as the number of 100 nanosecond increments since - January 1, 1601, in UTC time. - - When used in the KERB_VALIDATION_INFO, this is NDR encoded. The - UNICODE_STRING structure is defined as: - - typedef struct _UNICODE_STRING - USHORT Length; - USHORT MaximumLength; - [size_is(MaximumLength / 2), length_is((Length) / 2) ] - USHORT * Buffer; - } UNICODE_STRING; - - The Length field contains the number of bytes in the string, not - including the null terminator, and the MaximumLength field contains - the total number of bytes in the buffer containing the string. - - The GROUP_MEMBERSHIP structure contains the relative ID of a group - and the corresponding attributes for the group. - - typedef struct _GROUP_MEMBERSHIP { - ULONG RelativeId; - ULONG Attributes; - } *PGROUP_MEMBERSHIP; - - The group attributes must be: - - #define SE_GROUP_MANDATORY (0x00000001L) - #define SE_GROUP_ENABLED_BY_DEFAULT (0x00000002L) - #define SE_GROUP_ENABLED (0x00000004L) - - The SID structure is defined as follows: - - - typedef struct _SID_IDENTIFIER_AUTHORITY { - UCHAR Value[6]; - } SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY; - - The constant value for the NT Authority is - - #define SECURITY_NT_AUTHORITY {0,0,0,0,0,5} - - typedef struct _SID { - UCHAR Revision; - UCHAR SubAuthorityCount; - SID_IDENTIFIER_AUTHORITY IdentifierAuthority; - [size_is(SubAuthorityCount)] ULONG SubAuthority[*]; - } SID, *PSID; - - - -Brezak Category - Informational 5 - Windows 2000 Kerberos Authorization Data October 2002 - - - Other authorities are defined in the Microsoft Developer Network - Development Kit 3. - The SubAuthorityCount field contains the number of elements in the - actual SubAuthority conformant array. The maximum number of - subauthorities allowed is 15. - - The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and - their corresponding attributes: - - typedef struct _KERB_SID_AND_ATTRIBUTES { - PSID Sid; - ULONG Attributes; - } KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES; - - The attributes are the same as the group attributes defined above. - -5. Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM) - - The PAC contains two digital signatures: one using the key of the - server, and one using the key of the KDC. The signatures are present - for two reasons. First, the signature with the serverÆs key is - present to prevent a client from generating their own PAC and - sending it to the KDC as encrypted authorization data to be included - in tickets. Second, the signature with the KDCÆs key is present to - prevent an untrusted service from forging a ticket to itself with an - invalid PAC. The two signatures are sent in PAC_INFO_BUFFERs of type - PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM respectively. - - - The signatures are contained in the following structure: - - typedef struct _PAC_SIGNATURE_DATA { - ULONG SignatureType; - UCHAR Signature[1]; - } PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA; - - The fields are defined as follows: - - SignatureType - This field contains the type of checksum used to - create a signature. The checksum must be a keyed checksum. - - Signature - This field consists of an array of bytes containing the - checksum data. The length of bytes may be determined by the - wrapping PAC_INFO_BUFFER structure. - - For the serverÆs checksum, the key used to generate the signature - should be the same key used to encrypt the ticket. Thus, if the - enc_tkt_in_skey option is used, the session key from the serverÆs - TGT should be used. The Key used to encrypt ticket granting tickets - is used to generate the KDCÆs checksum. - - The checksums are computed as follows: - - -Brezak Category - Informational 6 - Windows 2000 Kerberos Authorization Data October 2002 - - - 1. The complete PAC is built, including space for both checksums - 2. The data portion of both checksums is zeroed. - 3. The entire PAC structure is checksummed with the serverÆs key, - and the result is stored in the serverÆs checksum structure. - 4. The serverÆs checksum is then checksummed with the KDC's key. - 5. The checksum with the KDC key is stored in the KDC's checksum - structure. - -6. PAC Request Pre-Auth Data - - Normally, the PAC is included in every pre-authenticated ticket - received from an AS request. However, a client may also explicitly - request either to include or to not include the PAC. This is done by - sending the PAC-REQUEST preauth data. - - This is an ASN.1 encoded structure. - - KERB-PA-PAC-REQUEST ::= SEQUENCE { - include-pac[0] BOOLEAN -- if TRUE, and no pac present, - -- include PAC. - ---If FALSE, and pac - -- PAC present, remove PAC - } - - The fields are defined as follows: - - include-pac - This field indicates whether a PAC should be included - or not. If the value is TRUE, a PAC will be included - independent of other preauth data. If the value is FALSE, - then no PAC will be included, even if other preauth data is - present. - - The preauth ID is: - #define KRB5_PADATA_PAC_REQUEST 128 - -7. Security Considerations - - Before the PAC data is used for access control, the - PAC_SERVER_CHECKSUM signature MUST be checked. This will verify that - the provider of the PAC data knows the server's secret key. - Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to - verify that the PAC was issued from the KDC and not placed in the - ticket by someone other than the KDC with access to the service key. - - Caution must be used with accepting the SIDs present in the logon- - info part of the PAC. Only SIDs from a domain that is authoritative - for a particular domain's SIDs should be used in the construction of - access tokens. If a SID is found to be from outside of a domain's - authoritative SID namespace, it MUST be ignored for purposes of - access control. - -8. References - - -Brezak Category - Informational 7 - Windows 2000 Kerberos Authorization Data October 2002 - - - - 1 Kohl, J., Neuman, C., "The Kerberos Network Authentication Service - (V5)", RFC 1510, September 1993 - - 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997 - - 3 Microsoft Developer's Network - http://msdn.microsoft.com - - -9. Author's Addresses - - John Brezak - Microsoft Corporation - One Microsoft Way - Redmond, Washington - Email: jbrezak@microsoft.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Brezak Category - Informational 8 - Windows 2000 Kerberos Authorization Data October 2002 - - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - - - - - - - - - - - - - - - - - - - - - - - - - - -Brezak Category - Informational 9
\ No newline at end of file |