idnits 2.17.1 draft-ietf-krb-wg-general-pac-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 '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 (September 8, 2011) is 4585 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 281, but not defined == Missing Reference: 'X680' is mentioned on line 340, but not defined -- Looks like a reference, but probably isn't: '0' on line 461 -- Looks like a reference, but probably isn't: '1' on line 462 -- Looks like a reference, but probably isn't: '2' on line 463 -- Looks like a reference, but probably isn't: '3' on line 420 == Unused Reference: 'RFC3961' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC3962' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'MIT-Athena' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'POSIX' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC2307' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 603, 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 (~~), 11 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: March 11, 2012 T. Hardjono, Ed. 6 MIT Kerberos Consortium 7 September 8, 2011 9 A Generalized PAC for Kerberos V5 10 draft-ietf-krb-wg-general-pac-00 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 March 11, 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-Domain-UUID . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 6 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 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1. PAD Format . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Data Structures and Extensions . . . . . . . . . . . . . . . . 10 76 6.1. SignedPricipalAuthorizationData . . . . . . . . . . . . . 10 77 6.2. GSS-API Authenticator Extension . . . . . . . . . . . . . 12 78 7. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 84 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 There is an increasing need today for Kerberos to support the 91 delivery and processing of authorization information pertaining to 92 the principals seeking access to the servers. Kerberos today is used 93 extensively for authentication to directory services within the 94 Enterprise. In many cases, a directory service is implemented as a 95 distributed database system organized across multiple realms. As 96 such, when a client in one realm seeks access to a directory service 97 component located within a different realm, information regarding 98 both the identity of the client and the permissions associated with 99 that client must be communicated across the realms. Currently there 100 does not exist a common and standardized structure in Kerberos (V5) 101 for conveying access control or authorization information. 103 This draft proposes a general authorization structure for Kerberos 104 that identifies a base set of common data elements or fields within 105 the authorization structure, as well as the format of that structure. 106 We refer to this data strcuture as the Principal Authorization Data 107 (PAD) structure in order to distinguish it from existing structures, 108 such as the Privilege Attribute Certificate defined by Microsoft in 109 [MS-PAC]. 111 2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 3. Use-Case: Cross-Realm Directory Services 119 In this section we discuss one of the primary use-case scenarios for 120 the Principal Authorization Data (PAD) structure within Kerberos V5. 121 In this use-case a client principal is seeking to access a service in 122 a different realm. Since the remote service does not have 123 authorization information regarding the client, it needs to obtain it 124 either from querying the directory service in its own realm or the 125 directory service located in the client's realm. It is here that a 126 common PAD structure becomes necessary and invaluable in order to 127 achieve a high-degree of interoperability between directory services 128 in distinct realms. 130 In this use-case a client principal C1 in realm R1 is seeking access 131 to services (or servers) located in a different realm R2. In 132 accessing local service S1 in realm R1 the client must first be 133 authenticated by KDC1 in that realm. A directory service (e.g. 135 LDAP) called D1 is used in realm R1 to perform authorization of the 136 client, after the client has been authenticated by KDC1. 138 When the client prinicipal later seeks to access services or 139 resources S2 in realm R2, following the usual Kerberos flow the 140 client must first obtain a cross-realm TGT from KDC1 (in realm R1) 141 and then present it to KDC2 (in realm R2) in order to obtain a 142 service-ticket for S2. However, one immediate issue is the fact that 143 service S2 does not have authorization information regarding the 144 permissions or privileges of client C1 in realm R1. The service S2 145 could query its own directory service D2 to obtain authorization 146 information pertaining to client C1. In the absence of such 147 information in D2, the service S2 could then perform a cross-realm 148 query to the directory services D1 operating in realm R1. 150 However, this cross-realm query from S2 to D1 is not only 151 inefficient, but it also implies knowledge of multiple eterogenous 152 systems by all actors. Two different realms may rely on completely 153 different infrastructures for user information storage, ranging from 154 different LDAP implementations with different schema conventions to 155 NIS, SQL databases, flat files, and so on. Every service in the 156 realm R2 would have to know what information system is in use in R1, 157 how to reach it, how to read and eventually how to map data from it. 158 Moreover security related aspects on the authentication of S2 by the 159 directory D1, the authorization of S2 to make such a query, the 160 protection of responses from D1 to S2, and so on, would have to be 161 addressed. 163 This use-case illustrates the need for a common PAD structure to 164 address this cross-realm authorization problem. In particular, the 165 PAD structure for the cross-realm access to remote services needs to 166 be contained or carried within cross-realm TGTs and service-tickets. 167 Such a PAD structure needs to carry enough authorization information 168 such that a decision can be made by service D2 in realm R2 regarding 169 the access request originating from the client principal C1 within 170 realm R1. 172 4. A Generalized Authorization Structure for Kerberos V5 174 4.1. Attributes 176 The following attributes are defined in this document: 178 o PAD-Realm 180 o PAD-Principal 181 o PAD-DNS-Domain 183 o PAD-Short-Domain 185 o PAD-Domain-UUID 187 o PAD-Posix-Username 189 o PAD-Posix-UID 191 o PAD-Posix-GID 193 o PAD-Posix-Gecos 195 o PAD-Posix-Homedir 197 o PAD-Posix-Shell 199 o PAD-Fullname 201 o PAD-AlternateNames 203 o PAD-Groups 205 These are each defined and discussed further below 207 4.2. PAD-Realm 209 The full Realm Name of the Realm the principal belongs to. 211 4.3. PAD-Principal 213 The name of the principal. Joined with the PAD-Realm component it 214 MUST match the full principal name of the owner of the ticket. 216 4.4. PAD-DNS-Domain 218 The DNS Domain name associated to the Realm. 220 4.5. 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. 226 4.6. PAD-Domain-UUID 228 A UUID that universally identifies the domain the following local 229 identifiers belongs to. This is used to differentiate between local 230 identifiers belonging to different domains/realms. 232 The UUID size can be dependent on the specific Domain type and 233 imlementation. However it SHOULD be not less than 96bit in size so 234 that chances of conflicts are relatively low. 236 If the UUID is shorter than 128bit it can be used as a 128bit UUID by 237 prepending enough bits all set to zero. 239 4.7. PAD-Posix-Username 241 This is the user name that correspond to the kerberos principal, this 242 is the name that SHOULD be used by the OS to represent the user. The 243 OS may decide to prefix or posfix this name with the PAD-Domain or 244 PAD-Realm names in case of name conflicts with local accounts. 246 4.8. PAD-Posix-UID 248 This is the UID Number associated to the user. This number is local 249 to the domain identified by PAD-Domain-UUID. 251 4.9. PAD-Posix-GID 253 This is the Primary GID Number associated to the user. This number 254 is local to the domain identified by PAD-Domain-UUID. 256 4.10. PAD-Posix-Gecos 258 The Gecos field for the User associated to the Principal if 259 available. Can be omitted. If not available PAD-Fullname can be 260 used instead. 262 4.11. PAD-Posix-Homedir 264 The home directory path relative to the local system, if available. 265 If not available local defined defaults apply. 267 4.12. PAD-Posix-Shell 269 The default shell for the user, defined as the path of the binary 270 relative to the local filesystem, if available. If not available 271 local defined defaults apply. 273 4.13. PAD-Fullname 275 The full name of the user if available. 277 4.14. PAD-AlternateNames 279 Alternate names can be used by application to identify a user by 280 means that differ from the user principal. Names are in string form 281 and utf8 encoded [UTF-8]. In order to allow applications to 282 recognize the name type without guesswork, alternate names are 283 prefixed with a string followed by the colon ':' character and the 284 name, without any space or other separation character. The following 285 Alternate names are currently recognized: EMAIL, OS, OPENID, OAUTH It 286 is allowed to include multiple alternate names of the same type. The 287 order in which they are provided represent the priority within the 288 same name type, if applications need to choose between names. 290 (TODO: need discussion on whether these needs labeled prefixes or 291 explicit attributes for each alternate representation etc...) 293 4.15. PAD-Groups 295 This is a structured attribute and defines the groups the principal 296 is member of. 298 The first value in the structure represents the Domain-UUID and is 299 optional. If missing the Domain UUID is assumed to be the one 300 defined in the PAD-Domain-UUID attribute. 302 Then an array of values that define the groups as follows. Each 303 group value includes 2 subvalues: 305 o (1) GID: This is the gid number of the group. 307 o (2) Name: This is the name of the group. 309 Multiple PAD-Groups attributes can be present at the same time. A 310 trusting KDC can augment the original user's set of groups by adding 311 a new PAD-Groups structure that contains groups local to the trusting 312 domain. In this case the Domain-UUID is required. The Domain UUID 313 is used for gid number conflict resolution when the PAC is 314 transmitted between services of different realms. 316 PAD-Groups are optional attributes and the KDC, upon PAC 317 revalidation, may decide to remove the original attributes that do 318 not belong to the KDC security domain in order to save space or to 319 censor information to avoid disclosing data to services. 321 4.16. PAD Mapped Attributes 323 In POSIX, users and groups ID are not universally unique, and 324 different Realms (even different machines within an authorization 325 realm actually) may have overlapping and conflicting IDs. If this is 326 the case, a trusting KDC may decide to re-map IDs coming from a 327 foreign Realm to help services with uid/gid mapping and avoid ID 328 conflicts that can lead to serious security issues. The original IDs 329 are generally preserved. 331 If multiple PAD buffers are received and one of them contains a PAD- 332 Domain-UUID that is recognized by the application to be the local 333 security domain identifier, then only the mapped attributes in this 334 buffer SHOULD be used for authorization purposes and the values of 335 the other buffers SHOULD be ignored. 337 5. Encoding 339 The Kerberos protocol is defined in [RFC4120] using Abstract Syntax 340 Notation One (ASN.1) [X680]. As such, this specification also uses 341 the ASN.1 syntax for specifying both the abstract layout of the PAD 342 attributes, as well as their encodings. 344 5.1. PAD Format 346 The information carried in the PAD need to be augment by some control 347 information and packaged in a way that makes it possible to devise 348 future extensions. 350 Additional information needed to validate the PAD: 352 o The expiration time (must be the same as the ticket expiration 353 time). 355 o The principal name (must be the same principal that owns the 356 ticket). 358 o The KDC signature (for re-validation purposes). 360 o The Service Signature (in order to trust the PAD has not been 361 tampered with). 363 o Optional Host Service Key Signature (for use by trusted services 364 on a host) 366 o Optional PUBKEY KDC Signature 367 This information is needed to validate the PAD and make sure it is 368 not modified, outdated, or contains information for a different 369 principal. 371 In order to make the PAD extensible and at the same time always 372 verifiable we propose that the PAD is embedded in a ASN.1 structure 373 that can contain multiple optional buffers identified by numbers (how 374 to assign numbers TBD). 376 Buffer number 0 is an ASN.1 strcture that includes all attributes 377 described in paragraph 4. This buffer is itself optional. 379 The whole structure with all its buffers is what is signed with the 380 KDC and the service keys. 382 The final structure to be included in AD-IF-RELEVANT container and 383 looks loosely like the following diagram. 385 ============================================ 386 |PAD: | 387 |------------------------------------------| 388 | KDC Signature (Checksum) | 389 |------------------------------------------| 390 | Service Signature (Checksum) | 391 |------------------------------------------| 392 | Trusted Service Signature (Optional) | 393 |------------------------------------------| 394 | Asymmetric Key KDC Signature (Optional) | 395 |------------------------------------------| 396 | /-PAD-DATA:----------------------------\ | 397 | | principal name | | 398 | | ticket expiration time | | 399 | | | | 400 | | Buf 0: --(optional)------- | | 401 | | | PAD Attributes ...| | | 402 | | | .. | | | 403 | | ------------------- | | 404 | | .... .... | | 405 | | Buf X: --(optional)------- | | 406 | | | .. | | | 407 | | ------------------- | | 408 | \--------------------------------------/ | 409 ============================================ 410 Figure 1: PAD Format 412 6. Data Structures and Extensions 414 6.1. SignedPricipalAuthorizationData 415 AD-PAD ::= SEQUENCE { 416 kdc-signature [0] Checksum, 417 svc-signature [1] Checksum, 418 trusted-svc-signature [2] PAD-OPT-Checksum OPTIONAL, 419 pubkey-signature [2] PAD-OPT-Checksum OPTIONAL, 420 pad-data [3] PAD-DATA 421 } 423 PAD-OPT-Checksum ::= SEQUENCE { 424 Identifier [0] Name, 425 Signature [1] Checksum 426 } 428 kdc-signature 429 A cryptographic checksum computed over the encoding of the 430 pad-data field, keyed with the krbtgt key. 431 Checksum type TBD. 433 svc-signature 434 A cryptographic checksum computed over the encoding of the 435 pad-data field, keyed with the service long term key. 436 Checksum type TBD. 438 Trusted-svc-signature 439 A principal name and a cryptographic checksum computed over the 440 encoding of the pad-data field, keyed with the long term key of 441 the principal name specified in the Name field. Unless otherwise 442 explicitly administratively configured, the key SHOULD be found 443 by substituting the service name component of the principal name 444 of the service with 'host'. 445 If the service is 'host' this checksum is redundant and can be 446 omitted. 447 If the resulting host/@REALM or the administratively 448 configured service is not found in the KDC database this 449 cheksum can be omitted. 450 Checksum type TBD. 452 pubkey-signature 453 A name identifying the asymmetric key-pair used. 454 A checksum computed over the encoding of the pad-data field using 455 the Private Key identified in the Name field. 456 If an asymmetric key is not available this checksum MUST be 457 omitted. 458 Signature type TBD. 460 PAD-DATA ::=SEQUENCE { 461 p-realm [0] Realm, 462 p-name [1] PrincipalName, 463 elements [2] SEQUENCE OF AuthorizationData 464 } 466 p-realm, p-name 467 The realm and name of the principal the authorization data 468 elements apply to. 470 elements 471 A sequence of authorization data elements issued by the KDC. 473 The AD-PAD data is intended to provide a means for a Kerberos 474 principal credentials to carry authorization data that the receiving 475 service can use to perform authorization decisions. 477 The KDC signature is required to allow the KDC to validate the data 478 withouth having to recompute the contents at every TGS request. 480 The SVC signature is required so that the Service can verify that the 481 authorization data has been validated by the KDC. 483 Both the Trusted Service Checksum and the asymmetric KDC Signature 484 are useful to verify the PAD authenticity on the same host, when the 485 PAD is received by a less trusted service and passed to a more 486 trusted service on the same host without the need for additional 487 roundtrips to the KDC. 489 The ad-type for AD-SIGNED-PAD is (TBD). 491 6.2. GSS-API Authenticator Extension 493 The Authenticator Checksum as defined in RFC 4121 limit the size of 494 delegated credentials in the KRB_CRED message to a size of 64KiB. 496 In order to be able to transfer larger messgaes an extension is 497 defined. This extension is used in stead of the Dlght/Deleg fields, 498 and the Dlght and Deleg fileds MUST not be included when this 499 extensions is appended to the authenticator. 501 The extension SHALL have the following format: 503 Octet Name Description 504 ----------------------------------------------------------------- 505 0..1 ExtN A 16bit value identifying the extension. 506 Represented in little-endian order; 507 Contains the hex value XX XX (XXXX). 509 2..5 Length The length of the Extended Delegation field. 510 Represented in little-endian order; 512 6..N Data A KRB_CRED message (N = Length + 6) 514 A new flag GSS_C_EXT_DELEG_FLAG with Value X is also defined. This 515 flag is used instead of GSS_C_DELEG_FLAG when the delegated 516 credentials are larger then 64KiB and cannot fit in the starndard 517 Deleg field. 519 Implementors SHOULD use this Extensions and this flag only if the 520 KRB_CRED message is larger than 64KiB and use the standard Deleg 521 field otherwise. 523 7. Assigned numbers 525 TBD 527 8. IANA Considerations 529 TBD. 531 9. Security Considerations 533 Although it is anticipated that the PAD structure itself will be 534 carried within a ticket and thereby protected using the existing 535 encryption methods on that ticket, there are a number of issues that 536 have bearings on the security of the entire Kerberos realm as whole. 537 Some of these issues are as follows: 539 o UID and GID Collisions: There is always the possibilty of collison 540 of numbers repressing a UID and a GID. This problem can be 541 remedied to a large degree by realms using an appropriate range 542 selection policy and algorithms. 544 o When collisions are detected the KDC or, alternatively, the 545 receiving Service MUST be able to remap IDs so that they do not 546 conflict with locally defined IDs 548 o Transit-domain issues: The PAC must be signed by the KDC that is 549 attaching it to a ticket with 2 different signatures. The service 550 signature so that the service can verify its KDC validated the 551 contents. The KDC signature, so that the OS can ask the KDC to 552 confirm the PAD has not been modified by a less trusted service. 553 An optional asymmetric key signature is also allowed if Keys are 554 available in order to avoid additional roundtrips. For cross- 555 realm tickets the "service" signature is made with the cross-realm 556 key. When a KDC receives a PAD it is allowed to modify it in any 557 way. It can filter out information or add information (like group 558 memberships defined locally). A KDC may also decide to change 559 information in different ways depending on what service it is 560 targeted to. 562 10. Acknowledgements 564 TBD. 566 11. References 568 11.1. Normative References 570 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 571 Kerberos 5", RFC 3961, February 2005. 573 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 574 Encryption for Kerberos 5", RFC 3962, February 2005. 576 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 577 Kerberos Network Authentication Service (V5)", RFC 4120, 578 July 2005. 580 11.2. Informative References 582 [MIT-Athena] 583 Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An 584 Authentication Service for Open Network Systems. In 585 Proceedings of the Winter 1988 Usenix Conference. 586 February.", 1988. 588 [MS-PAC] Microsoft, "Microsoft MS-PAC: Privilege Attribute 589 Certificate Data Structure (v20100711)", July 2010. 591 [POSIX] The Open Group, "Portable Operating System Interface 592 (POSIX.1-2008)", 2008. 594 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 595 Authentication Service (V5)", RFC 1510, September 1993. 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 601 Information Service", RFC 2307, March 1998. 603 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 604 Text on Security Considerations", BCP 72, RFC 3552, 605 July 2003. 607 [X.690] ISO, "ASN.1 encoding rules: Specification of Basic 608 Encoding Rules (BER), Canonical Encoding Rules (CER) and 609 Distinguished Encoding Rules (DER) - ITU-T Recommendation 610 X.690 (ISO/IEC International Standard 8825-1:1998)", 1997. 612 Appendix A. Additional Stuff 614 This becomes an Appendix. 616 Authors' Addresses 618 Simo Sorce (editor) 619 Red Hat 621 Email: ssorce@redhat.com 623 Tom Yu (editor) 624 MIT Kerberos Consortium 626 Email: tlyu@mit.edu 628 Thomas Hardjono (editor) 629 MIT Kerberos Consortium 631 Email: hardjono@mit.edu