idnits 2.17.1 draft-ietf-krb-wg-general-pac-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 (Oct 31, 2011) is 4560 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 297, but not defined == Missing Reference: 'X680' is mentioned on line 408, but not defined -- Looks like a reference, but probably isn't: '0' on line 532 -- Looks like a reference, but probably isn't: '1' on line 533 -- Looks like a reference, but probably isn't: '2' on line 534 -- Looks like a reference, but probably isn't: '3' on line 535 -- Looks like a reference, but probably isn't: '4' on line 536 == Unused Reference: 'RFC3961' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC3962' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'MIT-Athena' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'POSIX' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC2307' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 695, 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 (~~), 12 warnings (==), 7 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: May 3, 2012 T. Hardjono, Ed. 6 MIT Kerberos Consortium 7 Oct 31, 2011 9 A Generalized PAC for Kerberos V5 10 draft-ietf-krb-wg-general-pac-01 12 Abstract 14 This draft proposes a generalized authorization structure for the 15 Kerberos V5 protocol. Such an authorization structure would allow 16 for greater interoperability among directory services and other 17 related Kerberos services across differing realms. 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 May 3, 2012. 36 Copyright Notice 38 Copyright (c) 2011 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 Generalized Authorization Structure for Kerberos V5 . . . . 4 57 4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. PAD-Realm . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.3. PAD-Principal . . . . . . . . . . . . . . . . . . . . . . 5 60 4.4. PAD-DNS-Domain . . . . . . . . . . . . . . . . . . . . . . 5 61 4.5. PAD-Short-Domain . . . . . . . . . . . . . . . . . . . . . 5 62 4.6. PAD-UDID . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.7. PAD-Posix-Username . . . . . . . . . . . . . . . . . . . . 6 64 4.8. PAD-Posix-UID . . . . . . . . . . . . . . . . . . . . . . 6 65 4.9. PAD-Posix-GID . . . . . . . . . . . . . . . . . . . . . . 6 66 4.10. PAD-Posix-Gecos . . . . . . . . . . . . . . . . . . . . . 6 67 4.11. PAD-Posix-Homedir . . . . . . . . . . . . . . . . . . . . 6 68 4.12. PAD-Posix-Shell . . . . . . . . . . . . . . . . . . . . . 7 69 4.13. PAD-Fullname . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.14. PAD-AlternateNames . . . . . . . . . . . . . . . . . . . . 7 71 4.15. PAD-Groups . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.16. PAD Mapped Attributes . . . . . . . . . . . . . . . . . . 8 73 4.17. RFC2307 references for Directory Services backed KDCs . . 8 74 4.17.1. PAD-Posix-Username as 'uid' . . . . . . . . . . . . . 8 75 4.17.2. PAD-Posix-UID as 'uidNumber' . . . . . . . . . . . . 9 76 4.17.3. PAD-Posix-GID as 'gidNumber' . . . . . . . . . . . . 9 77 4.17.4. PAD-Posix-Gecos as 'gecos' . . . . . . . . . . . . . 9 78 4.17.5. PAD-Posix-Homedir as 'homeDirectory' . . . . . . . . 9 79 4.17.6. PAD-Posix-Shell as 'loginShell' . . . . . . . . . . . 9 80 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 5.1. PAD Format . . . . . . . . . . . . . . . . . . . . . . . . 9 82 6. Data Structures and Extensions . . . . . . . . . . . . . . . . 11 83 6.1. SignedPricipalAuthorizationData . . . . . . . . . . . . . 11 84 6.2. GSS-API Authenticator Extension . . . . . . . . . . . . . 13 85 7. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . . 14 86 8. Timeouts Considerations . . . . . . . . . . . . . . . . . . . 14 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 93 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Introduction 98 There is an increasing need today for Kerberos to support the 99 delivery and processing of authorization information pertaining to 100 the principals seeking access to the servers. Kerberos today is used 101 extensively for authentication to directory services within the 102 Enterprise. In many cases, a directory service is implemented as a 103 distributed database system organized across multiple realms. As 104 such, when a client in one realm seeks access to a directory service 105 component located within a different realm, information regarding 106 both the identity of the client and the permissions associated with 107 that client must be communicated across the realms. Currently there 108 does not exist a common and standardized structure in Kerberos (V5) 109 for conveying access control or authorization information. 111 This draft proposes a general authorization structure for Kerberos 112 that identifies a base set of common data elements or fields within 113 the authorization structure, as well as the format of that structure. 114 We refer to this data strcuture as the Principal Authorization Data 115 (PAD) structure in order to distinguish it from existing structures, 116 such as the Privilege Attribute Certificate defined by Microsoft in 117 [MS-PAC]. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 3. Use-Case: Cross-Realm Directory Services 127 In this section we discuss one of the primary use-case scenarios for 128 the Principal Authorization Data (PAD) structure within Kerberos V5. 129 In this use-case a client principal is seeking to access a service in 130 a different realm. Since the remote service does not have 131 authorization information regarding the client, it needs to obtain it 132 either from querying the directory service in its own realm or the 133 directory service located in the client's realm. It is here that a 134 common PAD structure becomes necessary and invaluable in order to 135 achieve a high-degree of interoperability between directory services 136 in distinct realms. 138 In this use-case a client principal C1 in realm R1 is seeking access 139 to services (or servers) located in a different realm R2. In 140 accessing local service S1 in realm R1 the client must first be 141 authenticated by KDC1 in that realm. A directory service (e.g. 143 LDAP) called D1 is used in realm R1 to perform authorization of the 144 client, after the client has been authenticated by KDC1. 146 When the client prinicipal later seeks to access services or 147 resources S2 in realm R2, following the usual Kerberos flow the 148 client must first obtain a cross-realm TGT from KDC1 (in realm R1) 149 and then present it to KDC2 (in realm R2) in order to obtain a 150 service-ticket for S2. However, one immediate issue is the fact that 151 service S2 does not have authorization information regarding the 152 permissions or privileges of client C1 in realm R1. The service S2 153 could query its own directory service D2 to obtain authorization 154 information pertaining to client C1. In the absence of such 155 information in D2, the service S2 could then perform a cross-realm 156 query to the directory services D1 operating in realm R1. 158 However, this cross-realm query from S2 to D1 is not only 159 inefficient, but it also implies knowledge of multiple heterogenous 160 systems by all actors. Two different realms may rely on completely 161 different infrastructures for user information storage, ranging from 162 different LDAP implementations with different schema conventions to 163 NIS, SQL databases, flat files, and so on. Every service in the 164 realm R2 would have to know what information system is in use in R1, 165 how to reach it, how to read and eventually how to map data from it. 166 Moreover security related aspects on the authentication of S2 by the 167 directory D1, the authorization of S2 to make such a query, the 168 protection of responses from D1 to S2, and so on, would have to be 169 addressed. 171 This use-case illustrates the need for a common PAD structure to 172 address this cross-realm authorization problem. In particular, the 173 PAD structure for the cross-realm access to remote services needs to 174 be contained or carried within cross-realm TGTs and service-tickets. 175 Such a PAD structure needs to carry enough authorization information 176 such that a decision can be made by service S2 in realm R2 regarding 177 the access request originating from the client principal C1 within 178 realm R1. 180 4. A Generalized Authorization Structure for Kerberos V5 182 4.1. Attributes 184 The following attributes are defined in this document: 186 o PAD-Realm 188 o PAD-Principal 189 o PAD-DNS-Domain 191 o PAD-Short-Domain 193 o PAD-UDID 195 o PAD-Posix-Username 197 o PAD-Posix-UID 199 o PAD-Posix-GID 201 o PAD-Posix-Gecos 203 o PAD-Posix-Homedir 205 o PAD-Posix-Shell 207 o PAD-Fullname 209 o PAD-AlternateNames 211 o PAD-Groups 213 These are each defined and discussed further below. 215 4.2. PAD-Realm 217 The full Realm Name of the Realm the authorization information 218 belongs to. 220 4.3. PAD-Principal 222 The name of the principal. Joined with the PAD-Realm component it 223 MUST match the full principal name of the owner of the ticket. 225 4.4. PAD-DNS-Domain 227 The DNS Domain name associated to the Realm. 229 4.5. PAD-Short-Domain 231 A short domain name that uniquely identifies, within the set of 232 trusted realms, the domain the principal belongs to. The short 233 Domain name is useful for representation purposes in the OS. A KDC 234 is allowed to change this field during validation. This may be done 235 to resolve name conflicts in large trust relationships. 237 4.6. PAD-UDID 239 A UDID is a Unique Domain Identifier. Ideally it universally 240 identifies the domain as the one the following local identifiers 241 belongs to. This is used to differentiate between local identifiers 242 belonging to different domains/realms. 244 The UDID size can be dependent on the specific Domain type and 245 imlementation. However it SHOULD be not less than 96 bits long so 246 that chances of conflicts are relatively low. A 96 bit long 247 identifier allows to construct a 128bit account identifier by 248 concatenating the UDID to the local account Identifier (32bit 249 quantity in POSIX). 251 For the purpose of this document the UDID is a compeltely opaque 252 number and implementations SHOULD not try to perform any enforcement 253 on the format of this number on receiving it. 255 4.7. PAD-Posix-Username 257 This is the user name that correspond to the kerberos principal, this 258 is the name that SHOULD be used by the OS to represent the user. The 259 OS may decide to prefix or suffix this name with the PAD-Domain or 260 PAD-Realm names in case of name conflicts with local accounts. 262 4.8. PAD-Posix-UID 264 This is the UID Number associated to the user. This number is local 265 to the domain identified by PAD-Domain-UUID. 267 4.9. PAD-Posix-GID 269 This is the Primary GID Number associated to the user. This number 270 is local to the domain identified by PAD-Domain-UUID. 272 4.10. PAD-Posix-Gecos 274 The Gecos field for the User associated to the Principal if 275 available. Can be omitted. If not available PAD-Fullname can be 276 used instead. 278 4.11. PAD-Posix-Homedir 280 The home directory path relative to the local system, if available. 281 If not available local defined defaults apply. 283 4.12. PAD-Posix-Shell 285 The default shell for the user, defined as the path of the binary 286 relative to the local filesystem, if available. If not available 287 local defined defaults apply. 289 4.13. PAD-Fullname 291 The full name of the user if available. 293 4.14. PAD-AlternateNames 295 Alternate names can be used by application to identify a user by 296 means that differ from the user principal. Names are in string form 297 and utf8 encoded [UTF-8]. In order to allow applications to 298 recognize the name type without guesswork, alternate names are 299 prefixed with a string followed by the colon ':' character and the 300 name, without any space or other separation character. The following 301 Alternate names are currently recognized: EMAIL, OS, OPENID, OAUTH It 302 is allowed to include multiple alternate names of the same type. The 303 order in which they are provided represent the priority within the 304 same name type, if applications need to choose between names. 306 (TODO: need discussion on whether these needs labeled prefixes or 307 explicit attributes for each alternate representation etc...) 309 4.15. PAD-Groups 311 This is a structured attribute and defines the groups the principal 312 is member of. 314 The first value in the structure represents the domain UDID and is 315 optional. If missing the domain UDID is assumed to be the one 316 defined in the PAD-UDID attribute. 318 Then an array of values that define the groups as follows. Each 319 group value includes 3 subvalues: 321 o (1) Name: This is the name of the group. 323 o (2) Type: Optional, type of group 325 o (3) ID: group ID. 327 If the type is missing it is assumed that the group is of type "Posix 328 Group" and the follwing ID is required and represents the gid number. 329 The type is represented through a simplified OID like type where only 330 2 levels are defined. 0.0 Is reserved for posix groups, and the 0 331 prefix is reserved to official RFX use. Additional Prefixes can be 332 assigned to organizations that request it for their purposes. 333 Assignment TBD. 335 Multiple PAD-Groups attributes can be present at the same time. A 336 trusting KDC can augment the original user's set of groups by adding 337 a new PAD-Groups structure that contains groups local to the trusting 338 domain. In this case the domain UDID is required. The domain UDID 339 is used for gid number conflict resolution when the PAC is 340 transmitted between services of different realms. 342 PAD-Groups are optional attributes and the KDC, upon PAC 343 revalidation, may decide to remove the original attributes that do 344 not belong to the KDC security domain in order to save space or to 345 censor information to avoid disclosing data to services. 347 4.16. PAD Mapped Attributes 349 In POSIX, users and groups ID are not universally unique, and 350 different Realms (even different machines within an authorization 351 realm actually) may have overlapping and conflicting IDs. If this is 352 the case, a trusting KDC may decide to re-map IDs coming from a 353 foreign Realm to help services with uid/gid mapping and avoid ID 354 conflicts that can lead to serious security issues. The original IDs 355 are generally preserved. 357 If multiple PAD buffers are received and one of them contains a PAD- 358 UDID that is recognized by the application to be the local security 359 domain identifier, then only the mapped attributes in this buffer 360 SHOULD be used for authorization purposes. 362 4.17. RFC2307 references for Directory Services backed KDCs 364 A few attributes contain the keyword 'Posix' in their name. These 365 attributes are usually represented by RFC2307 in Directory Services. 366 If the primary store for these attributes is a Directory the 367 following equivalence with RFC2307 defined attributes can be used. 369 4.17.1. PAD-Posix-Username as 'uid' 371 The PAD-Posix-Username is the User ID, and its syntax is equivalent 372 to the attribute named 'uid' in RFC 2307. This attribute is defined 373 in RFC 4519 (2.39). The attribute is defined as multivalued in RFC 374 4519 but in this context only a single value is allowed. To define 375 aliases refer to the attribute PAD-AlternateNames. 377 4.17.2. PAD-Posix-UID as 'uidNumber' 379 The PAD-Posix-UID is the User's Unique Identifier Number, and its 380 syntax is equivalent to the attribute named 'uidNumber' in RFC 2307. 382 4.17.3. PAD-Posix-GID as 'gidNumber' 384 The PAD-Posix-GID is the User's Primary Group Identifier Number, and 385 its syntax is equivalent to the attribute named 'gidNumber' in RFC 386 2307. 388 4.17.4. PAD-Posix-Gecos as 'gecos' 390 The PAD-Posix-Gecos is the User's Common Name, although, 391 traditionally, this field has been used to convey additional 392 information beyond the user's full name. Its syntax is equivalent to 393 the attribute named 'gecos' in RFC 2307. 395 4.17.5. PAD-Posix-Homedir as 'homeDirectory' 397 The PAD-Posix-Homedir is the User's LOCAL home directory. Its syntax 398 is equivalent to the attribute named 'homeDirectory' in RFC 2307. 400 4.17.6. PAD-Posix-Shell as 'loginShell' 402 The PAD-Posix-Shell is the User's preferred login shell. Its syntax 403 is equivalent to the attribute named 'loginShell' in RFC 2307. 405 5. Encoding 407 The Kerberos protocol is defined in [RFC4120] using Abstract Syntax 408 Notation One (ASN.1) [X680]. As such, this specification also uses 409 the ASN.1 syntax for specifying both the abstract layout of the PAD 410 attributes, as well as their encodings. 412 5.1. PAD Format 414 The information carried in the PAD needs to be augmented by some 415 control information and packaged in a way that makes it possible to 416 devise future extensions. 418 Additional information needed to validate the PAD: 420 o The expiration time (must be the same as the ticket expiration 421 time). 423 o The principal name (must be the same principal that owns the 424 ticket). 426 o The KDC signature (for re-validation purposes). 428 o The Service Signature (in order to trust the PAD has not been 429 tampered with). 431 o Optional Trusted Service Key Signature (for use by trusted 432 services on a host) 434 o Optional PUBKEY KDC Signature 436 This information is needed to validate the PAD and make sure it is 437 not modified, outdated, or contains information for a different 438 principal. 440 In order to make the PAD extensible and at the same time always 441 verifiable we propose that the PAD is embedded in a ASN.1 structure 442 that can contain multiple optional buffers identified by numbers (how 443 to assign numbers TBD). 445 Buffer number 0 is an ASN.1 strcture that includes all attributes 446 described in paragraph 4. This buffer is itself optional. 448 The whole structure with all its buffers is what is signed with the 449 KDC and the service keys. 451 The final structure to be included in AD-IF-RELEVANT container and 452 looks loosely like the following diagram. 454 ============================================ 455 |PAD: | 456 |------------------------------------------| 457 | KDC Signature (Checksum) | 458 |------------------------------------------| 459 | Service Signature (Checksum) | 460 |------------------------------------------| 461 | Trusted Service Signature (Optional) | 462 |------------------------------------------| 463 | Asymmetric Key KDC Signature (Optional) | 464 |------------------------------------------| 465 | /-PAD-DATA:----------------------------\ | 466 | | principal name | | 467 | | expiration time | | 468 | | session ID | | 469 | | | | 470 | | Buf 0: --(optional)------- | | 471 | | | PAD Attributes ...| | | 472 | | | .. | | | 473 | | ------------------- | | 474 | | .... .... | | 475 | | Buf X: --(optional)------- | | 476 | | | .. | | | 477 | | ------------------- | | 478 | \--------------------------------------/ | 479 ============================================ 481 Figure 1: PAD Format 483 6. Data Structures and Extensions 485 6.1. SignedPricipalAuthorizationData 486 AD-PAD ::= SEQUENCE { 487 kdc-signature [0] Checksum, 488 svc-signature [1] Checksum, 489 trusted-svc-signature [2] PAD-OPT-Checksum OPTIONAL, 490 pubkey-signature [2] PAD-OPT-Checksum OPTIONAL, 491 pad-data [3] PAD-DATA 492 } 494 PAD-OPT-Checksum ::= SEQUENCE { 495 Identifier [0] Name, 496 Signature [1] Checksum 497 } 499 kdc-signature 500 A cryptographic checksum computed over the encoding of the 501 pad-data field, keyed with the krbtgt key. 502 Checksum type TBD. 504 svc-signature 505 A cryptographic checksum computed over the encoding of the 506 pad-data field, keyed with the service long term key. 507 Checksum type TBD. 509 Trusted-svc-signature 510 A principal name and a cryptographic checksum computed over the 511 encoding of the pad-data field, keyed with the long term key of 512 the principal name specified in the Name field. Unless otherwise 513 explicitly administratively configured, the key SHOULD be found 514 by substituting the service name component of the principal name 515 of the service with 'host'. 516 If the service is 'host' this checksum is redundant and can be 517 omitted. 518 If the resulting host/@REALM or the administratively 519 configured service is not found in the KDC database this 520 cheksum can be omitted. 521 Checksum type TBD. 523 pubkey-signature 524 A name identifying the asymmetric key-pair used. 525 A checksum computed over the encoding of the pad-data field using 526 the Private Key identified in the Name field. 527 If an asymmetric key is not available this checksum MUST be 528 omitted. 529 Signature type TBD. 531 PAD-DATA ::=SEQUENCE { 532 p-realm [0] Realm, 533 p-name [1] PrincipalName, 534 expiration [2] Date, 535 session-id [3] TBD, 536 elements [4] SEQUENCE OF AuthorizationData 537 } 539 p-realm, p-name 540 The realm and name of the principal the authorization data 541 elements apply to. 543 expiration 544 The Expitration Date of the Authorization Data. Normally this is 545 the same as the original TGT expiration date. 547 session-id 548 A random number that uniquely ties any following ticket this PAD 549 Data is associated to with the original TGT Released to the user 551 elements 552 A sequence of authorization data elements issued by the KDC. 554 The AD-PAD data is intended to provide a means for a Kerberos 555 principal credentials to carry authorization data that the receiving 556 service can use to perform authorization decisions. 558 The KDC signature is required to allow the KDC to validate the data 559 withouth having to recompute the contents at every TGS request. 561 The SVC signature is required so that the Service can verify that the 562 authorization data has been validated by the KDC. 564 Both the Trusted Service Checksum and the asymmetric KDC Signature 565 are useful to verify the PAD authenticity on the same host, when the 566 PAD is received by a less trusted service and passed to a more 567 trusted service on the same host without the need for additional 568 roundtrips to the KDC. 570 The ad-type for AD-SIGNED-PAD is (TBD). 572 6.2. GSS-API Authenticator Extension 574 The Authenticator Checksum as defined in RFC 4121 limit the size of 575 delegated credentials in the KRB_CRED message to a size of 64KiB. 577 In order to be able to transfer larger messgaes an extension is 578 defined. This extension is used in stead of the Dlght/Deleg fields, 579 and the Dlght and Deleg fileds MUST not be included when this 580 extensions is appended to the authenticator. 582 The extension SHALL have the following format which is drafted 583 according to [draft-ietf-krb-wg-gss-cb-hash-agility]: 585 Octet Name Description 586 ----------------------------------------------------------------- 587 0..3 ExtN A 16bit value identifying the extension. 588 Represented in big-endian order; 589 Contains the hex value 0xXXXXXXXX. 591 4..7 Length The length of the Extended Delegation field. 592 Represented in big-endian order; 594 8..N Data A KRB_CRED message (N = Length + 8) 596 A new flag GSS_C_EXT_DELEG_FLAG with Value X is also defined. This 597 flag is used instead of GSS_C_DELEG_FLAG when the delegated 598 credentials are larger then 64KiB and cannot fit in the starndard 599 Deleg field. 601 Implementors SHOULD use this Extensions and this flag only if the 602 KRB_CRED message is larger than 64KiB and use the standard Deleg 603 field otherwise. 605 7. Assigned numbers 607 TBD 609 8. Timeouts Considerations 611 Current implementations dpend on very strict timeouts on obtaining AS 612 Replies. In popular implementations the client will timeout if it 613 doesn't receive a reply within 1 second. Adding authorization data 614 may involve lookups to external (to the KDC) data sources. 615 Implementors should consider whether the current timeout is still 616 reasonbale in light of the additional processing KDCs may be required 617 to do. 619 9. IANA Considerations 621 TBD. 623 10. Security Considerations 625 Although it is anticipated that the PAD structure itself will be 626 carried within a ticket and thereby protected using the existing 627 encryption methods on that ticket, there are a number of issues that 628 have bearings on the security of the entire Kerberos realm as a 629 whole. Some of these issues are as follows: 631 o UID and GID Collisions: There is always the possibilty of collison 632 of numbers repressing a UID and a GID. This problem can be 633 remedied to a large degree by realms using an appropriate range 634 selection policy and algorithms. 636 o When collisions are detected the KDC or, alternatively, the 637 receiving Service MUST be able to remap IDs so that they do not 638 conflict with locally defined IDs 640 o Transit-domain issues: The PAC must be signed by the KDC that is 641 attaching it to a ticket with 2 different signatures. The service 642 signature so that the service can verify its KDC validated the 643 contents. The KDC signature, so that the OS can ask the KDC to 644 confirm the PAD has not been modified by a less trusted service. 645 An optional asymmetric key signature is also allowed if Keys are 646 available in order to avoid additional roundtrips. For cross- 647 realm tickets the "service" signature is made with the cross-realm 648 key. When a KDC receives a PAD it is allowed to modify it in any 649 way. It can filter out information or add information (like group 650 memberships defined locally). A KDC may also decide to change 651 information in different ways depending on what service it is 652 targeted to. 654 11. Acknowledgements 656 TBD. 658 12. References 660 12.1. Normative References 662 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 663 Kerberos 5", RFC 3961, February 2005. 665 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 666 Encryption for Kerberos 5", RFC 3962, February 2005. 668 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 669 Kerberos Network Authentication Service (V5)", RFC 4120, 670 July 2005. 672 12.2. Informative References 674 [MIT-Athena] 675 Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An 676 Authentication Service for Open Network Systems. In 677 Proceedings of the Winter 1988 Usenix Conference. 678 February.", 1988. 680 [MS-PAC] Microsoft, "Microsoft MS-PAC: Privilege Attribute 681 Certificate Data Structure (v20100711)", July 2010. 683 [POSIX] The Open Group, "Portable Operating System Interface 684 (POSIX.1-2008)", 2008. 686 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 687 Authentication Service (V5)", RFC 1510, September 1993. 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, March 1997. 692 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 693 Information Service", RFC 2307, March 1998. 695 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 696 Text on Security Considerations", BCP 72, RFC 3552, 697 July 2003. 699 [X.690] ISO, "ASN.1 encoding rules: Specification of Basic 700 Encoding Rules (BER), Canonical Encoding Rules (CER) and 701 Distinguished Encoding Rules (DER) - ITU-T Recommendation 702 X.690 (ISO/IEC International Standard 8825-1:1998)", 1997. 704 Appendix A. Additional Stuff 706 This becomes an Appendix. 708 Authors' Addresses 710 Simo Sorce (editor) 711 Red Hat 713 Email: ssorce@redhat.com 715 Tom Yu (editor) 716 MIT Kerberos Consortium 718 Email: tlyu@mit.edu 720 Thomas Hardjono (editor) 721 MIT Kerberos Consortium 723 Email: hardjono@mit.edu