idnits 2.17.1 draft-ietf-krb-wg-pad-00.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 8, 2012) is 4461 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 291, but not defined == Missing Reference: 'X680' is mentioned on line 411, but not defined -- Looks like a reference, but probably isn't: '0' on line 484 -- Looks like a reference, but probably isn't: '1' on line 485 -- Looks like a reference, but probably isn't: '2' on line 486 -- Looks like a reference, but probably isn't: '3' on line 487 == Unused Reference: 'RFC3961' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC3962' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'MIT-Athena' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'MS-PAC' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'POSIX' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC2307' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 635, 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 11, 2012 T. Hardjono, Ed. 6 MIT Kerberos Consortium 7 Feb 8, 2012 9 Principal Authorization Data Containers 10 draft-ietf-krb-wg-pad-00 12 Abstract 14 This draft proposes a generalized authorization structure to transmit 15 authorization data for the Kerberos V5 protocol. Such an 16 authorization structure would allow for greater interoperability 17 among directory services and other related Kerberos services across 18 differing realms. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 11, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Use-Case: Cross-Realm Directory Services . . . . . . . . . . . 4 57 4. A POSIX Authorization Structure for Kerberos V5 . . . . . . . 5 58 4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. PAD-Realm . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3. PAD-DNS-Domain . . . . . . . . . . . . . . . . . . . . . . 6 61 4.4. PAD-Short-Domain . . . . . . . . . . . . . . . . . . . . . 6 62 4.5. PAD-UDID . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.6. PAD-Posix-Username . . . . . . . . . . . . . . . . . . . . 7 64 4.7. PAD-Posix-UID . . . . . . . . . . . . . . . . . . . . . . 7 65 4.8. PAD-Posix-GID . . . . . . . . . . . . . . . . . . . . . . 7 66 4.9. PAD-Posix-Gecos . . . . . . . . . . . . . . . . . . . . . 7 67 4.10. PAD-Posix-Homedir . . . . . . . . . . . . . . . . . . . . 7 68 4.11. PAD-Posix-Shell . . . . . . . . . . . . . . . . . . . . . 7 69 4.12. PAD-Fullname . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.13. PAD-AlternateNames . . . . . . . . . . . . . . . . . . . . 8 71 4.14. PAD-Groups . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.15. PAD Mapped Attributes . . . . . . . . . . . . . . . . . . 9 73 4.16. RFC2307 references for Directory Services backed KDCs . . 9 74 4.16.1. PAD-Posix-Username as 'uid' . . . . . . . . . . . . . 9 75 4.16.2. PAD-Posix-UID as 'uidNumber' . . . . . . . . . . . . 9 76 4.16.3. PAD-Posix-GID as 'gidNumber' . . . . . . . . . . . . 10 77 4.16.4. PAD-Posix-Gecos as 'gecos' . . . . . . . . . . . . . 10 78 4.16.5. PAD-Posix-Homedir as 'homeDirectory' . . . . . . . . 10 79 4.16.6. PAD-Posix-Shell as 'loginShell' . . . . . . . . . . . 10 80 5. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 6.1. PAD Format . . . . . . . . . . . . . . . . . . . . . . . . 10 83 7. Data Structures and Extensions . . . . . . . . . . . . . . . . 12 84 7.1. AD-ID-ANCHOR . . . . . . . . . . . . . . . . . . . . . . . 12 85 7.2. AD-PAD-DATA . . . . . . . . . . . . . . . . . . . . . . . 13 86 7.3. GSS-API Authenticator Extension . . . . . . . . . . . . . 13 87 8. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . . 14 88 9. Timeouts Considerations . . . . . . . . . . . . . . . . . . . 14 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 94 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 95 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 98 1. Introduction 100 There is an increasing need today for Kerberos to support the 101 delivery and processing of authorization information pertaining to 102 the principals seeking access to the servers. Kerberos today is used 103 extensively for authentication to directory services within the 104 Enterprise. In many cases, a directory service is implemented as a 105 distributed database system organized across multiple realms. As 106 such, when a client in one realm seeks access to a directory service 107 component located within a different realm, information regarding 108 both the identity of the client and the permissions associated with 109 that client must be communicated across the realms. Currently there 110 does not exist a common and standardized structure in Kerberos (V5) 111 for conveying access control or authorization information. 113 This draft proposes an authorization data element for Kerberos that 114 contains information that is useful for dynamically updating the user 115 and group directory information in a POSIX system, usually in the 116 course of a login type activity. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. Use-Case: Cross-Realm Directory Services 126 In this section we discuss one of the primary use-case scenarios for 127 the POSIX Authorization Data (PAD) structure within Kerberos V5. In 128 this use-case a client principal is seeking to access a service in a 129 different realm. Since the remote service does not have 130 authorization information regarding the client, it needs to obtain it 131 either from querying the directory service in its own realm or the 132 directory service located in the client's realm. It is here that a 133 common PAD structure becomes necessary and invaluable in order to 134 achieve a high-degree of interoperability between directory services 135 in distinct realms. 137 In this use-case a client principal C1 in realm R1 is seeking access 138 to services (or servers) located in a different realm R2. In 139 accessing local service S1 in realm R1 the client must first be 140 authenticated by KDC1 in that realm. A directory service (e.g. 141 LDAP) called D1 is used in realm R1 to perform authorization of the 142 client, after the client has been authenticated by KDC1. 144 When the client prinicipal later seeks to access services or 145 resources S2 in realm R2, following the usual Kerberos flow the 146 client must first obtain a cross-realm TGT from KDC1 (in realm R1) 147 and then present it to KDC2 (in realm R2) in order to obtain a 148 service-ticket for S2. However, one immediate issue is the fact that 149 service S2 does not have authorization information regarding the 150 permissions or privileges of client C1 in realm R1. The service S2 151 could query its own directory service D2 to obtain authorization 152 information pertaining to client C1. In the absence of such 153 information in D2, the service S2 could then perform a cross-realm 154 query to the directory services D1 operating in realm R1. 156 However, this cross-realm query from S2 to D1 is not only 157 inefficient, but it also implies knowledge of multiple heterogenous 158 systems by all actors. Two different realms may rely on completely 159 different infrastructures for user information storage, ranging from 160 different LDAP implementations with different schema conventions to 161 NIS, SQL databases, flat files, and so on. Every service in the 162 realm R2 would have to know what information system is in use in R1, 163 how to reach it, how to read and eventually how to map data from it. 164 Moreover security related aspects on the authentication of S2 by the 165 directory D1, the authorization of S2 to make such a query, the 166 protection of responses from D1 to S2, and so on, would have to be 167 addressed. 169 This use-case illustrates the need for a common PAD structure to 170 address this cross-realm authorization problem. In particular, the 171 PAD structure for the cross-realm access to remote services needs to 172 be contained or carried within cross-realm TGTs and service-tickets. 173 Such a PAD structure needs to carry enough authorization information 174 such that a decision can be made by service S2 in realm R2 regarding 175 the access request originating from the client principal C1 within 176 realm R1. 178 4. A POSIX Authorization Structure for Kerberos V5 180 4.1. Attributes 182 The following attributes are defined in this document: 184 o PAD-Realm 186 o PAD-DNS-Domain 188 o PAD-Short-Domain 189 o PAD-UDID 191 o PAD-Posix-Username 193 o PAD-Posix-UID 195 o PAD-Posix-GID 197 o PAD-Posix-Gecos 199 o PAD-Posix-Homedir 201 o PAD-Posix-Shell 203 o PAD-Fullname 205 o PAD-AlternateNames 207 o PAD-Groups 209 These are each defined and discussed further below. 211 4.2. PAD-Realm 213 The full Realm Name of the Realm the authorization information 214 applies to. 216 4.3. PAD-DNS-Domain 218 The DNS Domain name associated to the Realm. 220 4.4. PAD-Short-Domain 222 A short domain name that uniquely identifies, within the set of 223 trusted realms, the domain the principal belongs to. The short 224 Domain name is useful for representation purposes in the OS. A KDC 225 MUST verify this name is unique and correctly represnt a remote realm 226 within its own realm and is allowed to change or remove this field 227 during validation. This may be done to resolve name conflicts in 228 large trust relationships. 230 4.5. PAD-UDID 232 A UDID is a Unique Domain Identifier. Ideally it universally 233 identifies the domain as the one the following local identifiers 234 belongs to. This is used to differentiate between local identifiers 235 belonging to different domains/realms. 237 The UDID size can be dependent on the specific Domain type and 238 imlementation. However it SHOULD be not less than 96 bits long so 239 that chances of conflicts are relatively low. A 96 bit long 240 identifier allows to construct a 128bit account identifier by 241 concatenating the UDID to the local account Identifier (32bit 242 quantity in POSIX). 244 For the purpose of this document the UDID is a compeltely opaque 245 number and implementations SHOULD not try to perform any enforcement 246 on the format of this number on receiving it. 248 4.6. PAD-Posix-Username 250 This is the user name that correspond to the kerberos principal, this 251 is the name that SHOULD be used by the OS to represent the user. The 252 OS may decide to prefix or suffix this name with the PAD-Domain or 253 PAD-Realm or PAD-Short-Domain names to avoid name conflicts with 254 local accounts. 256 4.7. PAD-Posix-UID 258 This is the UID Number associated to the user. This number is local 259 to the domain identified by PAD-UDID. 261 4.8. PAD-Posix-GID 263 This is the Primary GID Number associated to the user. This number 264 is local to the domain identified by PAD-UDID. 266 4.9. PAD-Posix-Gecos 268 The Gecos field for the User associated to the Principal if 269 available. Can be omitted. If not available PAD-Fullname can be 270 used instead. 272 4.10. PAD-Posix-Homedir 274 The home directory path relative to the local system, if available. 275 If not available local defined defaults apply. 277 4.11. PAD-Posix-Shell 279 The default shell for the user, defined as the path of the binary 280 relative to the local filesystem, if available. If not available 281 local defined defaults apply. 283 4.12. PAD-Fullname 285 The full name of the user if available. 287 4.13. PAD-AlternateNames 289 Alternate names can be used by application to identify a user by 290 means that differ from the user principal. Names are in string form 291 and utf8 encoded [UTF-8]. In order to allow applications to 292 recognize the name type without guesswork, alternate names are 293 prefixed with a string followed by the colon ':' character and the 294 name, without any space or other separation character. The following 295 Alternate names are currently recognized: EMAIL, OS, OPENID, OAUTH It 296 is allowed to include multiple alternate names of the same type. The 297 order in which they are provided represent the priority within the 298 same name type, if applications need to choose between names. 300 (TODO: need discussion on whether these needs labeled prefixes or 301 explicit attributes for each alternate representation etc...) 303 4.14. PAD-Groups 305 This is a structured attribute and defines the groups the principal 306 is member of. 308 The first value in the structure represents the domain UDID and is 309 optional. If missing the domain UDID is assumed to be the one 310 defined in the PAD-UDID attribute. 312 Then an array of values that define the groups as follows. Each 313 group value includes 3 subvalues: 315 o (1) Name: This is the name of the group. 317 o (2) Type: Optional, type of group 319 o (3) ID: group ID. 321 If the type is missing it is assumed that the group is of type "Posix 322 Group" and the follwing ID is required and represents the gid number. 323 The type is represented through a simplified OID like type where only 324 2 levels are defined. 0.0 Is reserved for posix groups, and the 0 325 prefix is reserved to official RFX use. Additional Prefixes can be 326 assigned to organizations that request it for their purposes. 327 Assignment TBD. 329 Multiple PAD-Groups attributes can be present at the same time. A 330 trusting KDC can augment the original user's set of groups by adding 331 a new PAD-Groups structure that contains groups local to the trusting 332 domain. In this case the domain UDID is required. The domain UDID 333 is used for gid number conflict resolution when the PAC is 334 transmitted between services of different realms. 336 PAD-Groups are optional attributes and the KDC, upon PAC 337 revalidation, may decide to remove the original attributes that do 338 not belong to the KDC security domain in order to save space or to 339 censor information to avoid disclosing data to services. 341 4.15. PAD Mapped Attributes 343 In POSIX, users and groups ID are not universally unique, and 344 different Realms (even different machines within an authorization 345 realm actually) may have overlapping and conflicting IDs. If this is 346 the case, a trusting KDC may decide to re-map IDs coming from a 347 foreign Realm to help services with uid/gid mapping and avoid ID 348 conflicts that can lead to serious security issues. The original IDs 349 are generally preserved. 351 If multiple PAD buffers are received and one of them contains a PAD- 352 UDID that is recognized by the application to be the local security 353 domain identifier, then only the mapped attributes in this buffer 354 SHOULD be used for authorization purposes. 356 4.16. RFC2307 references for Directory Services backed KDCs 358 A few attributes contain the keyword 'Posix' in their name. These 359 attributes are usually represented by RFC2307 in Directory Services. 360 If the primary store for these attributes is a Directory the 361 following equivalence with RFC2307 defined attributes can be used. 363 4.16.1. PAD-Posix-Username as 'uid' 365 The PAD-Posix-Username is the User ID, and its syntax is equivalent 366 to the attribute named 'uid' in RFC 2307. This attribute is defined 367 in RFC 4519 (2.39). The attribute is defined as multivalued in RFC 368 4519 but in this context only a single value is allowed. To define 369 aliases refer to the attribute PAD-AlternateNames. 371 4.16.2. PAD-Posix-UID as 'uidNumber' 373 The PAD-Posix-UID is the User's Unique Identifier Number, and its 374 syntax is equivalent to the attribute named 'uidNumber' in RFC 2307. 376 4.16.3. PAD-Posix-GID as 'gidNumber' 378 The PAD-Posix-GID is the User's Primary Group Identifier Number, and 379 its syntax is equivalent to the attribute named 'gidNumber' in RFC 380 2307. 382 4.16.4. PAD-Posix-Gecos as 'gecos' 384 The PAD-Posix-Gecos is the User's Common Name, although, 385 traditionally, this field has been used to convey additional 386 information beyond the user's full name. Its syntax is equivalent to 387 the attribute named 'gecos' in RFC 2307. 389 4.16.5. PAD-Posix-Homedir as 'homeDirectory' 391 The PAD-Posix-Homedir is the User's LOCAL home directory. Its syntax 392 is equivalent to the attribute named 'homeDirectory' in RFC 2307. 394 4.16.6. PAD-Posix-Shell as 'loginShell' 396 The PAD-Posix-Shell is the User's preferred login shell. Its syntax 397 is equivalent to the attribute named 'loginShell' in RFC 2307. 399 5. Validation 401 The PAD information is used by a client to perform authorization, 402 therefore this information is highly sensitive and must be validated 403 to insure no tampering has occured. 405 Therefore AD-PAD elements MUST always be transmitted contained within 406 an AD-CAMMAC element 408 6. Encoding 410 The Kerberos protocol is defined in [RFC4120] using Abstract Syntax 411 Notation One (ASN.1) [X680]. As such, this specification also uses 412 the ASN.1 syntax for specifying both the abstract layout of the PAD 413 attributes, as well as their encodings. 415 6.1. PAD Format 417 The information carried in the PAD needs to be augmented by some 418 identifying information in order to tie the PAD data to a specific 419 identity within the Kerberos Realm. 421 In order to allow additional authorization data to be tied together 422 and at the same time always verifiable we propose that the PAD is 423 delivered as an AD element within a AD-CAMMAC. 425 An AuthorizationData element of type AD-ID-ANCHOR is used to bind the 426 PAD to the ticket and the authorization data within the PAD to the 427 specific principal. This element MUST always be present and SHOULD 428 be validated. If this element is not available the PAD data MUST be 429 discarded and considered untrustworthy. 431 The AD-ID-ANCHOR includes the full principal name, the realm, the 432 expiration time and an optional session ID. 434 The ad-type for AD-PAD-ANCHOR is (TBD). 436 The AD-PAD-DATA include the attributes described in paragraph 4. 438 The ad-type for AD-PAD-DATA is (TBD). 440 The final structure used to deliver the PAD Data looks loosely like 441 the following diagram. 443 ==AD-CAMMAC================================= 444 |------------------------------------------| 445 | KDC Signature (Checksum) | 446 |------------------------------------------| 447 | Service Signature (Checksum) | 448 |------------------------------------------| 449 | Trusted Service Signature (Optional) | 450 |------------------------------------------| 451 | Asymmetric Key KDC Signature (Optional) | 452 |------------------------------------------| 453 | /-AuthorizationData SEQUENCE:----------\ | 454 | | | | 455 | | 0: --AD-ID-ANCHOR---- | | 456 | | | Realm | | | 457 | | | PrincipalName | | | 458 | | | expiration time | | | 459 | | | session ID | | | 460 | | ------------------ | | 461 | | | | 462 | | 1: --AD-PAD-DATA------ | | 463 | | | PAD Attributes ...| | | 464 | | | .. | | | 465 | | ------------------- | | 466 | | .... .... | | 467 | | X: --AD-XXXXXXX------- | | 468 | | | .. | | | 469 | | ------------------- | | 470 | \--------------------------------------/ | 471 ============================================ 473 Figure 1: PAD Format 475 7. Data Structures and Extensions 477 7.1. AD-ID-ANCHOR 479 The AD-ID-ANCHOR is intended to provide a means to bind data, carried 480 in a AD-CAMMAC element, to a specific Identity (Principal), and 481 optionally to a specific Ticket by using the session ID element. 483 AD-ID-ANCHOR ::=SEQUENCE { 484 p-realm [0] Realm, 485 p-name [1] PrincipalName, 486 expiration [2] KerberosTime, 487 session-id [3] TBD 488 } 490 p-realm, p-name 491 The realm and name of the principal the authorization data 492 elements apply to. 494 expiration 495 The Expitration Date of the Authorization Data. Normally this is 496 the same as the original TGT expiration date. 498 session-id 499 A random number that uniquely ties any following ticket this PAD 500 Data is associated to with the original TGT Released to the user 502 7.2. AD-PAD-DATA 504 The AD-PAD-DATA data is intended to provide a means for a Kerberos 505 principal credentials to carry authorization data that the receiving 506 service can use to perform authorization decisions. 508 AD-PAD-ANCHOR ::=SEQUENCE { 509 TBD 510 } 512 7.3. GSS-API Authenticator Extension 514 The Authenticator Checksum as defined in RFC 4121 limit the size of 515 delegated credentials in the KRB_CRED message to a size of 64KiB. 517 In order to be able to transfer larger messgaes an extension is 518 defined. This extension is used in stead of the Dlght/Deleg fields, 519 and the Dlght and Deleg fileds MUST not be included when this 520 extensions is appended to the authenticator. 522 The extension SHALL have the following format which is drafted 523 according to [draft-ietf-krb-wg-gss-cb-hash-agility]: 525 Octet Name Description 526 ----------------------------------------------------------------- 527 0..3 ExtN A 16bit value identifying the extension. 528 Represented in big-endian order; 529 Contains the hex value 0xXXXXXXXX. 531 4..7 Length The length of the Extended Delegation field. 532 Represented in big-endian order; 534 8..N Data A KRB_CRED message (N = Length + 8) 536 A new flag GSS_C_EXT_DELEG_FLAG with Value X is also defined. This 537 flag is used instead of GSS_C_DELEG_FLAG when the delegated 538 credentials are larger then 64KiB and cannot fit in the starndard 539 Deleg field. 541 Implementors SHOULD use this Extensions and this flag only if the 542 KRB_CRED message is larger than 64KiB and use the standard Deleg 543 field otherwise. 545 8. Assigned numbers 547 TBD 549 9. Timeouts Considerations 551 Current implementations depend on very strict timeouts on obtaining 552 AS Replies. In popular implementations the client will timeout if it 553 doesn't receive a reply within 1 second. Adding authorization data 554 may involve lookups to external (to the KDC) data sources. 555 Implementors should consider whether the current timeout is still 556 reasonbale in light of the additional processing KDCs may be required 557 to do. 559 10. IANA Considerations 561 TBD. 563 11. Security Considerations 565 Although it is anticipated that the PAD structure itself will be 566 carried within a ticket and thereby protected using the existing 567 encryption methods on that ticket, there are a number of issues that 568 have bearings on the security of the entire Kerberos realm as a 569 whole. Some of these issues are as follows: 571 o UID and GID Collisions: There is always the possibilty of collison 572 of numbers repressing a UID and a GID. This problem can be 573 remedied to a large degree by realms using an appropriate range 574 selection policy and algorithms. 576 o When collisions are detected the KDC or, alternatively, the 577 receiving Service MUST be able to remap IDs so that they do not 578 conflict with locally defined IDs 580 o Transit-domain issues: The PAC must be signed by the KDC that is 581 attaching it to a ticket with 2 different signatures. The service 582 signature so that the service can verify its KDC validated the 583 contents. The KDC signature, so that the OS can ask the KDC to 584 confirm the PAD has not been modified by a less trusted service. 585 An optional asymmetric key signature is also allowed if Keys are 586 available in order to avoid additional roundtrips. For cross- 587 realm tickets the "service" signature is made with the cross-realm 588 key. When a KDC receives a PAD it is allowed to modify it in any 589 way. It can filter out information or add information (like group 590 memberships defined locally). A KDC may also decide to change 591 information in different ways depending on what service it is 592 targeted to. 594 12. Acknowledgements 596 TBD. 598 13. References 600 13.1. Normative References 602 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 603 Kerberos 5", RFC 3961, February 2005. 605 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 606 Encryption for Kerberos 5", RFC 3962, February 2005. 608 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 609 Kerberos Network Authentication Service (V5)", RFC 4120, 610 July 2005. 612 13.2. Informative References 614 [MIT-Athena] 615 Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An 616 Authentication Service for Open Network Systems. In 617 Proceedings of the Winter 1988 Usenix Conference. 618 February.", 1988. 620 [MS-PAC] Microsoft, "Microsoft MS-PAC: Privilege Attribute 621 Certificate Data Structure (v20100711)", July 2010. 623 [POSIX] The Open Group, "Portable Operating System Interface 624 (POSIX.1-2008)", 2008. 626 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 627 Authentication Service (V5)", RFC 1510, September 1993. 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 633 Information Service", RFC 2307, March 1998. 635 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 636 Text on Security Considerations", BCP 72, RFC 3552, 637 July 2003. 639 [X.690] ISO, "ASN.1 encoding rules: Specification of Basic 640 Encoding Rules (BER), Canonical Encoding Rules (CER) and 641 Distinguished Encoding Rules (DER) - ITU-T Recommendation 642 X.690 (ISO/IEC International Standard 8825-1:1998)", 1997. 644 Appendix A. Additional Stuff 646 This becomes an Appendix. 648 Authors' Addresses 650 Simo Sorce (editor) 651 Red Hat 653 Email: ssorce@redhat.com 654 Tom Yu (editor) 655 MIT Kerberos Consortium 657 Email: tlyu@mit.edu 659 Thomas Hardjono (editor) 660 MIT Kerberos Consortium 662 Email: hardjono@mit.edu