idnits 2.17.00 (12 Aug 2021) /tmp/idnits22571/draft-ietf-krb-wg-pad-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: For the purpose of this document the UDID is a compeltely opaque number and implementations SHOULD not try to perform any enforcement on the format of this number on receiving it. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In order to be able to transfer larger messgaes an extension is defined. This extension is used in stead of the Dlght/Deleg fields, and the Dlght and Deleg fileds MUST not be included when this extensions is appended to the authenticator. -- The document date (Feb 9, 2012) is 3747 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UTF-8' is mentioned on line 290, but not defined == Missing Reference: 'X680' is mentioned on line 410, but not defined -- Looks like a reference, but probably isn't: '0' on line 483 -- Looks like a reference, but probably isn't: '1' on line 484 -- Looks like a reference, but probably isn't: '2' on line 485 -- Looks like a reference, but probably isn't: '3' on line 486 == Unused Reference: 'RFC3961' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC3962' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'MIT-Athena' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'MS-PAC' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'POSIX' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC2307' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 634, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Sorce, Ed. 3 Internet-Draft Red Hat 4 Intended status: Standards Track T. Yu, Ed. 5 Expires: August 12, 2012 T. Hardjono, Ed. 6 MIT Kerberos Consortium 7 Feb 9, 2012 9 POSIX Authorization Data 10 draft-ietf-krb-wg-pad-01 12 Abstract 14 This document proposes a Kerberos Authorization Data element 15 containing user and group directory information similar to that 16 provided by RFC 2307, typically used by POSIX and POSIX-like systems 17 in the course of login type activities. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 12, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Use-Case: Cross-Realm Directory Services . . . . . . . . . . . 3 56 4. A POSIX Authorization Structure for Kerberos V5 . . . . . . . 4 57 4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. PAD-Realm . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.3. PAD-DNS-Domain . . . . . . . . . . . . . . . . . . . . . . 5 60 4.4. PAD-Short-Domain . . . . . . . . . . . . . . . . . . . . . 5 61 4.5. PAD-UDID . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.6. PAD-Posix-Username . . . . . . . . . . . . . . . . . . . . 6 63 4.7. PAD-Posix-UID . . . . . . . . . . . . . . . . . . . . . . 6 64 4.8. PAD-Posix-GID . . . . . . . . . . . . . . . . . . . . . . 6 65 4.9. PAD-Posix-Gecos . . . . . . . . . . . . . . . . . . . . . 6 66 4.10. PAD-Posix-Homedir . . . . . . . . . . . . . . . . . . . . 6 67 4.11. PAD-Posix-Shell . . . . . . . . . . . . . . . . . . . . . 6 68 4.12. PAD-Fullname . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.13. PAD-AlternateNames . . . . . . . . . . . . . . . . . . . . 7 70 4.14. PAD-Groups . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.15. PAD Mapped Attributes . . . . . . . . . . . . . . . . . . 8 72 4.16. RFC2307 references for Directory Services backed KDCs . . 8 73 4.16.1. PAD-Posix-Username as 'uid' . . . . . . . . . . . . . 8 74 4.16.2. PAD-Posix-UID as 'uidNumber' . . . . . . . . . . . . 8 75 4.16.3. PAD-Posix-GID as 'gidNumber' . . . . . . . . . . . . 9 76 4.16.4. PAD-Posix-Gecos as 'gecos' . . . . . . . . . . . . . 9 77 4.16.5. PAD-Posix-Homedir as 'homeDirectory' . . . . . . . . 9 78 4.16.6. PAD-Posix-Shell as 'loginShell' . . . . . . . . . . . 9 79 5. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6.1. PAD Format . . . . . . . . . . . . . . . . . . . . . . . . 9 82 7. Data Structures and Extensions . . . . . . . . . . . . . . . . 11 83 7.1. AD-ID-ANCHOR . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.2. AD-PAD-DATA . . . . . . . . . . . . . . . . . . . . . . . 12 85 7.3. GSS-API Authenticator Extension . . . . . . . . . . . . . 12 86 8. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . . 13 87 9. Timeouts Considerations . . . . . . . . . . . . . . . . . . . 13 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 93 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 94 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 There is an increasing need today for Kerberos to support the 100 delivery and processing of authorization information pertaining to 101 the principals seeking access to the servers. Kerberos today is used 102 extensively for authentication to directory services within the 103 Enterprise. In many cases, a directory service is implemented as a 104 distributed database system organized across multiple realms. As 105 such, when a client in one realm seeks access to a directory service 106 component located within a different realm, information regarding 107 both the identity of the client and the permissions associated with 108 that client must be communicated across the realms. Currently there 109 does not exist a common and standardized structure in Kerberos (V5) 110 for conveying access control or authorization information. 112 This draft proposes an authorization data element for Kerberos that 113 contains information that is useful for dynamically updating the user 114 and group directory information in a POSIX system, usually in the 115 course of a login type activity. 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3. Use-Case: Cross-Realm Directory Services 125 In this section we discuss one of the primary use-case scenarios for 126 the POSIX Authorization Data (PAD) structure within Kerberos V5. In 127 this use-case a client principal is seeking to access a service in a 128 different realm. Since the remote service does not have 129 authorization information regarding the client, it needs to obtain it 130 either from querying the directory service in its own realm or the 131 directory service located in the client's realm. It is here that a 132 common PAD structure becomes necessary and invaluable in order to 133 achieve a high-degree of interoperability between directory services 134 in distinct realms. 136 In this use-case a client principal C1 in realm R1 is seeking access 137 to services (or servers) located in a different realm R2. In 138 accessing local service S1 in realm R1 the client must first be 139 authenticated by KDC1 in that realm. A directory service (e.g. 140 LDAP) called D1 is used in realm R1 to perform authorization of the 141 client, after the client has been authenticated by KDC1. 143 When the client prinicipal later seeks to access services or 144 resources S2 in realm R2, following the usual Kerberos flow the 145 client must first obtain a cross-realm TGT from KDC1 (in realm R1) 146 and then present it to KDC2 (in realm R2) in order to obtain a 147 service-ticket for S2. However, one immediate issue is the fact that 148 service S2 does not have authorization information regarding the 149 permissions or privileges of client C1 in realm R1. The service S2 150 could query its own directory service D2 to obtain authorization 151 information pertaining to client C1. In the absence of such 152 information in D2, the service S2 could then perform a cross-realm 153 query to the directory services D1 operating in realm R1. 155 However, this cross-realm query from S2 to D1 is not only 156 inefficient, but it also implies knowledge of multiple heterogenous 157 systems by all actors. Two different realms may rely on completely 158 different infrastructures for user information storage, ranging from 159 different LDAP implementations with different schema conventions to 160 NIS, SQL databases, flat files, and so on. Every service in the 161 realm R2 would have to know what information system is in use in R1, 162 how to reach it, how to read and eventually how to map data from it. 163 Moreover security related aspects on the authentication of S2 by the 164 directory D1, the authorization of S2 to make such a query, the 165 protection of responses from D1 to S2, and so on, would have to be 166 addressed. 168 This use-case illustrates the need for a common PAD structure to 169 address this cross-realm authorization problem. In particular, the 170 PAD structure for the cross-realm access to remote services needs to 171 be contained or carried within cross-realm TGTs and service-tickets. 172 Such a PAD structure needs to carry enough authorization information 173 such that a decision can be made by service S2 in realm R2 regarding 174 the access request originating from the client principal C1 within 175 realm R1. 177 4. A POSIX Authorization Structure for Kerberos V5 179 4.1. Attributes 181 The following attributes are defined in this document: 183 o PAD-Realm 185 o PAD-DNS-Domain 187 o PAD-Short-Domain 188 o PAD-UDID 190 o PAD-Posix-Username 192 o PAD-Posix-UID 194 o PAD-Posix-GID 196 o PAD-Posix-Gecos 198 o PAD-Posix-Homedir 200 o PAD-Posix-Shell 202 o PAD-Fullname 204 o PAD-AlternateNames 206 o PAD-Groups 208 These are each defined and discussed further below. 210 4.2. PAD-Realm 212 The full Realm Name of the Realm the authorization information 213 applies to. 215 4.3. PAD-DNS-Domain 217 The DNS Domain name associated to the Realm. 219 4.4. PAD-Short-Domain 221 A short domain name that uniquely identifies, within the set of 222 trusted realms, the domain the principal belongs to. The short 223 Domain name is useful for representation purposes in the OS. A KDC 224 MUST verify this name is unique and correctly represnt a remote realm 225 within its own realm and is allowed to change or remove this field 226 during validation. This may be done to resolve name conflicts in 227 large trust relationships. 229 4.5. PAD-UDID 231 A UDID is a Unique Domain Identifier. Ideally it universally 232 identifies the domain as the one the following local identifiers 233 belongs to. This is used to differentiate between local identifiers 234 belonging to different domains/realms. 236 The UDID size can be dependent on the specific Domain type and 237 imlementation. However it SHOULD be not less than 96 bits long so 238 that chances of conflicts are relatively low. A 96 bit long 239 identifier allows to construct a 128bit account identifier by 240 concatenating the UDID to the local account Identifier (32bit 241 quantity in POSIX). 243 For the purpose of this document the UDID is a compeltely opaque 244 number and implementations SHOULD not try to perform any enforcement 245 on the format of this number on receiving it. 247 4.6. PAD-Posix-Username 249 This is the user name that correspond to the kerberos principal, this 250 is the name that SHOULD be used by the OS to represent the user. The 251 OS may decide to prefix or suffix this name with the PAD-Domain or 252 PAD-Realm or PAD-Short-Domain names to avoid name conflicts with 253 local accounts. 255 4.7. PAD-Posix-UID 257 This is the UID Number associated to the user. This number is local 258 to the domain identified by PAD-UDID. 260 4.8. PAD-Posix-GID 262 This is the Primary GID Number associated to the user. This number 263 is local to the domain identified by PAD-UDID. 265 4.9. PAD-Posix-Gecos 267 The Gecos field for the User associated to the Principal if 268 available. Can be omitted. If not available PAD-Fullname can be 269 used instead. 271 4.10. PAD-Posix-Homedir 273 The home directory path relative to the local system, if available. 274 If not available local defined defaults apply. 276 4.11. PAD-Posix-Shell 278 The default shell for the user, defined as the path of the binary 279 relative to the local filesystem, if available. If not available 280 local defined defaults apply. 282 4.12. PAD-Fullname 284 The full name of the user if available. 286 4.13. PAD-AlternateNames 288 Alternate names can be used by application to identify a user by 289 means that differ from the user principal. Names are in string form 290 and utf8 encoded [UTF-8]. In order to allow applications to 291 recognize the name type without guesswork, alternate names are 292 prefixed with a string followed by the colon ':' character and the 293 name, without any space or other separation character. The following 294 Alternate names are currently recognized: EMAIL, OS, OPENID, OAUTH It 295 is allowed to include multiple alternate names of the same type. The 296 order in which they are provided represent the priority within the 297 same name type, if applications need to choose between names. 299 (TODO: need discussion on whether these needs labeled prefixes or 300 explicit attributes for each alternate representation etc...) 302 4.14. PAD-Groups 304 This is a structured attribute and defines the groups the principal 305 is member of. 307 The first value in the structure represents the domain UDID and is 308 optional. If missing the domain UDID is assumed to be the one 309 defined in the PAD-UDID attribute. 311 Then an array of values that define the groups as follows. Each 312 group value includes 3 subvalues: 314 o (1) Name: This is the name of the group. 316 o (2) Type: Optional, type of group 318 o (3) ID: group ID. 320 If the type is missing it is assumed that the group is of type "Posix 321 Group" and the follwing ID is required and represents the gid number. 322 The type is represented through a simplified OID like type where only 323 2 levels are defined. 0.0 Is reserved for posix groups, and the 0 324 prefix is reserved to official RFX use. Additional Prefixes can be 325 assigned to organizations that request it for their purposes. 326 Assignment TBD. 328 Multiple PAD-Groups attributes can be present at the same time. A 329 trusting KDC can augment the original user's set of groups by adding 330 a new PAD-Groups structure that contains groups local to the trusting 331 domain. In this case the domain UDID is required. The domain UDID 332 is used for gid number conflict resolution when the PAC is 333 transmitted between services of different realms. 335 PAD-Groups are optional attributes and the KDC, upon PAC 336 revalidation, may decide to remove the original attributes that do 337 not belong to the KDC security domain in order to save space or to 338 censor information to avoid disclosing data to services. 340 4.15. PAD Mapped Attributes 342 In POSIX, users and groups ID are not universally unique, and 343 different Realms (even different machines within an authorization 344 realm actually) may have overlapping and conflicting IDs. If this is 345 the case, a trusting KDC may decide to re-map IDs coming from a 346 foreign Realm to help services with uid/gid mapping and avoid ID 347 conflicts that can lead to serious security issues. The original IDs 348 are generally preserved. 350 If multiple PAD buffers are received and one of them contains a PAD- 351 UDID that is recognized by the application to be the local security 352 domain identifier, then only the mapped attributes in this buffer 353 SHOULD be used for authorization purposes. 355 4.16. RFC2307 references for Directory Services backed KDCs 357 A few attributes contain the keyword 'Posix' in their name. These 358 attributes are usually represented by RFC2307 in Directory Services. 359 If the primary store for these attributes is a Directory the 360 following equivalence with RFC2307 defined attributes can be used. 362 4.16.1. PAD-Posix-Username as 'uid' 364 The PAD-Posix-Username is the User ID, and its syntax is equivalent 365 to the attribute named 'uid' in RFC 2307. This attribute is defined 366 in RFC 4519 (2.39). The attribute is defined as multivalued in RFC 367 4519 but in this context only a single value is allowed. To define 368 aliases refer to the attribute PAD-AlternateNames. 370 4.16.2. PAD-Posix-UID as 'uidNumber' 372 The PAD-Posix-UID is the User's Unique Identifier Number, and its 373 syntax is equivalent to the attribute named 'uidNumber' in RFC 2307. 375 4.16.3. PAD-Posix-GID as 'gidNumber' 377 The PAD-Posix-GID is the User's Primary Group Identifier Number, and 378 its syntax is equivalent to the attribute named 'gidNumber' in RFC 379 2307. 381 4.16.4. PAD-Posix-Gecos as 'gecos' 383 The PAD-Posix-Gecos is the User's Common Name, although, 384 traditionally, this field has been used to convey additional 385 information beyond the user's full name. Its syntax is equivalent to 386 the attribute named 'gecos' in RFC 2307. 388 4.16.5. PAD-Posix-Homedir as 'homeDirectory' 390 The PAD-Posix-Homedir is the User's LOCAL home directory. Its syntax 391 is equivalent to the attribute named 'homeDirectory' in RFC 2307. 393 4.16.6. PAD-Posix-Shell as 'loginShell' 395 The PAD-Posix-Shell is the User's preferred login shell. Its syntax 396 is equivalent to the attribute named 'loginShell' in RFC 2307. 398 5. Validation 400 The PAD information is used by a client to perform authorization, 401 therefore this information is highly sensitive and must be validated 402 to insure no tampering has occured. 404 Therefore AD-PAD elements MUST always be transmitted contained within 405 an AD-CAMMAC element 407 6. Encoding 409 The Kerberos protocol is defined in [RFC4120] using Abstract Syntax 410 Notation One (ASN.1) [X680]. As such, this specification also uses 411 the ASN.1 syntax for specifying both the abstract layout of the PAD 412 attributes, as well as their encodings. 414 6.1. PAD Format 416 The information carried in the PAD needs to be augmented by some 417 identifying information in order to tie the PAD data to a specific 418 identity within the Kerberos Realm. 420 In order to allow additional authorization data to be tied together 421 and at the same time always verifiable we propose that the PAD is 422 delivered as an AD element within a AD-CAMMAC. 424 An AuthorizationData element of type AD-ID-ANCHOR is used to bind the 425 PAD to the ticket and the authorization data within the PAD to the 426 specific principal. This element MUST always be present and SHOULD 427 be validated. If this element is not available the PAD data MUST be 428 discarded and considered untrustworthy. 430 The AD-ID-ANCHOR includes the full principal name, the realm, the 431 expiration time and an optional session ID. 433 The ad-type for AD-PAD-ANCHOR is (TBD). 435 The AD-PAD-DATA include the attributes described in paragraph 4. 437 The ad-type for AD-PAD-DATA is (TBD). 439 The final structure used to deliver the PAD Data looks loosely like 440 the following diagram. 442 ==AD-CAMMAC================================= 443 |------------------------------------------| 444 | KDC Signature (Checksum) | 445 |------------------------------------------| 446 | Service Signature (Checksum) | 447 |------------------------------------------| 448 | Trusted Service Signature (Optional) | 449 |------------------------------------------| 450 | Asymmetric Key KDC Signature (Optional) | 451 |------------------------------------------| 452 | /-AuthorizationData SEQUENCE:----------\ | 453 | | | | 454 | | 0: --AD-ID-ANCHOR---- | | 455 | | | Realm | | | 456 | | | PrincipalName | | | 457 | | | expiration time | | | 458 | | | session ID | | | 459 | | ------------------ | | 460 | | | | 461 | | 1: --AD-PAD-DATA------ | | 462 | | | PAD Attributes ...| | | 463 | | | .. | | | 464 | | ------------------- | | 465 | | .... .... | | 466 | | X: --AD-XXXXXXX------- | | 467 | | | .. | | | 468 | | ------------------- | | 469 | \--------------------------------------/ | 470 ============================================ 472 Figure 1: PAD Format 474 7. Data Structures and Extensions 476 7.1. AD-ID-ANCHOR 478 The AD-ID-ANCHOR is intended to provide a means to bind data, carried 479 in a AD-CAMMAC element, to a specific Identity (Principal), and 480 optionally to a specific Ticket by using the session ID element. 482 AD-ID-ANCHOR ::=SEQUENCE { 483 p-realm [0] Realm, 484 p-name [1] PrincipalName, 485 expiration [2] KerberosTime, 486 session-id [3] TBD 487 } 489 p-realm, p-name 490 The realm and name of the principal the authorization data 491 elements apply to. 493 expiration 494 The Expitration Date of the Authorization Data. Normally this is 495 the same as the original TGT expiration date. 497 session-id 498 A random number that uniquely ties any following ticket this PAD 499 Data is associated to with the original TGT Released to the user 501 7.2. AD-PAD-DATA 503 The AD-PAD-DATA data is intended to provide a means for a Kerberos 504 principal credentials to carry authorization data that the receiving 505 service can use to perform authorization decisions. 507 AD-PAD-ANCHOR ::=SEQUENCE { 508 TBD 509 } 511 7.3. GSS-API Authenticator Extension 513 The Authenticator Checksum as defined in RFC 4121 limit the size of 514 delegated credentials in the KRB_CRED message to a size of 64KiB. 516 In order to be able to transfer larger messgaes an extension is 517 defined. This extension is used in stead of the Dlght/Deleg fields, 518 and the Dlght and Deleg fileds MUST not be included when this 519 extensions is appended to the authenticator. 521 The extension SHALL have the following format which is drafted 522 according to [draft-ietf-krb-wg-gss-cb-hash-agility]: 524 Octet Name Description 525 ----------------------------------------------------------------- 526 0..3 ExtN A 16bit value identifying the extension. 527 Represented in big-endian order; 528 Contains the hex value 0xXXXXXXXX. 530 4..7 Length The length of the Extended Delegation field. 531 Represented in big-endian order; 533 8..N Data A KRB_CRED message (N = Length + 8) 535 A new flag GSS_C_EXT_DELEG_FLAG with Value X is also defined. This 536 flag is used instead of GSS_C_DELEG_FLAG when the delegated 537 credentials are larger then 64KiB and cannot fit in the starndard 538 Deleg field. 540 Implementors SHOULD use this Extensions and this flag only if the 541 KRB_CRED message is larger than 64KiB and use the standard Deleg 542 field otherwise. 544 8. Assigned numbers 546 TBD 548 9. Timeouts Considerations 550 Current implementations depend on very strict timeouts on obtaining 551 AS Replies. In popular implementations the client will timeout if it 552 doesn't receive a reply within 1 second. Adding authorization data 553 may involve lookups to external (to the KDC) data sources. 554 Implementors should consider whether the current timeout is still 555 reasonbale in light of the additional processing KDCs may be required 556 to do. 558 10. IANA Considerations 560 TBD. 562 11. Security Considerations 564 Although it is anticipated that the PAD structure itself will be 565 carried within a ticket and thereby protected using the existing 566 encryption methods on that ticket, there are a number of issues that 567 have bearings on the security of the entire Kerberos realm as a 568 whole. Some of these issues are as follows: 570 o UID and GID Collisions: There is always the possibilty of collison 571 of numbers repressing a UID and a GID. This problem can be 572 remedied to a large degree by realms using an appropriate range 573 selection policy and algorithms. 575 o When collisions are detected the KDC or, alternatively, the 576 receiving Service MUST be able to remap IDs so that they do not 577 conflict with locally defined IDs 579 o Transit-domain issues: The PAC must be signed by the KDC that is 580 attaching it to a ticket with 2 different signatures. The service 581 signature so that the service can verify its KDC validated the 582 contents. The KDC signature, so that the OS can ask the KDC to 583 confirm the PAD has not been modified by a less trusted service. 584 An optional asymmetric key signature is also allowed if Keys are 585 available in order to avoid additional roundtrips. For cross- 586 realm tickets the "service" signature is made with the cross-realm 587 key. When a KDC receives a PAD it is allowed to modify it in any 588 way. It can filter out information or add information (like group 589 memberships defined locally). A KDC may also decide to change 590 information in different ways depending on what service it is 591 targeted to. 593 12. Acknowledgements 595 TBD. 597 13. References 599 13.1. Normative References 601 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 602 Kerberos 5", RFC 3961, February 2005. 604 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 605 Encryption for Kerberos 5", RFC 3962, February 2005. 607 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 608 Kerberos Network Authentication Service (V5)", RFC 4120, 609 July 2005. 611 13.2. Informative References 613 [MIT-Athena] 614 Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An 615 Authentication Service for Open Network Systems. In 616 Proceedings of the Winter 1988 Usenix Conference. 617 February.", 1988. 619 [MS-PAC] Microsoft, "Microsoft MS-PAC: Privilege Attribute 620 Certificate Data Structure (v20100711)", July 2010. 622 [POSIX] The Open Group, "Portable Operating System Interface 623 (POSIX.1-2008)", 2008. 625 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 626 Authentication Service (V5)", RFC 1510, September 1993. 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, March 1997. 631 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 632 Information Service", RFC 2307, March 1998. 634 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 635 Text on Security Considerations", BCP 72, RFC 3552, 636 July 2003. 638 [X.690] ISO, "ASN.1 encoding rules: Specification of Basic 639 Encoding Rules (BER), Canonical Encoding Rules (CER) and 640 Distinguished Encoding Rules (DER) - ITU-T Recommendation 641 X.690 (ISO/IEC International Standard 8825-1:1998)", 1997. 643 Appendix A. Additional Stuff 645 This becomes an Appendix. 647 Authors' Addresses 649 Simo Sorce (editor) 650 Red Hat 652 Email: ssorce@redhat.com 653 Tom Yu (editor) 654 MIT Kerberos Consortium 656 Email: tlyu@mit.edu 658 Thomas Hardjono (editor) 659 MIT Kerberos Consortium 661 Email: hardjono@mit.edu