idnits 2.17.1 draft-ietf-krb-wg-kdc-model-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 551. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5651 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) == Outdated reference: A later version (-08) exists of draft-ietf-krb-wg-kerberos-set-passwd-07 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KERBEROS WORKING GROUP Johansson 3 Internet-Draft Stockholm university 4 Intended status: Standards Track November 3, 2008 5 Expires: May 7, 2009 7 An information model for Kerberos version 5 8 draft-ietf-krb-wg-kdc-model-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 7, 2009. 35 Abstract 37 This document describes an information model for Kerberos version 5 38 from the point of view of an administrative service. There is no 39 standard for administrating a kerberos 5 KDC. This document 40 describes the services exposed by an administrative interface to a 41 KDC. 43 Table of Contents 45 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. How to interpret RFC2119 terms . . . . . . . . . . . . . . . . 5 48 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 49 5. Information model demarcation . . . . . . . . . . . . . . . . 7 50 6. Information model specification . . . . . . . . . . . . . . . 8 51 6.1. Principal . . . . . . . . . . . . . . . . . . . . . . . . 8 52 6.1.1. Principal: Attributes . . . . . . . . . . . . . . . . 8 53 6.1.2. Principal: Associations . . . . . . . . . . . . . . . 9 54 6.1.3. Principal: Remarks . . . . . . . . . . . . . . . . . . 10 55 6.2. KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 6.2.1. KeySet: Attributes . . . . . . . . . . . . . . . . . . 10 57 6.2.2. KeySet: Associations . . . . . . . . . . . . . . . . . 10 58 6.2.3. KeySet: Remarks . . . . . . . . . . . . . . . . . . . 10 59 6.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6.3.1. Key: Attributes . . . . . . . . . . . . . . . . . . . 11 61 6.3.2. Key: Associations . . . . . . . . . . . . . . . . . . 12 62 6.3.3. Key: Remarks . . . . . . . . . . . . . . . . . . . . . 12 63 6.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 6.4.1. Policy: Attributes . . . . . . . . . . . . . . . . . . 12 65 6.4.2. Mandatory-to-implement Policy . . . . . . . . . . . . 13 66 7. Implementation Scenarios . . . . . . . . . . . . . . . . . . . 14 67 7.1. LDAP backend to KDC . . . . . . . . . . . . . . . . . . . 14 68 7.2. LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 14 69 7.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 Intellectual Property and Copyright Statements . . . . . . . . . . 19 78 1. Requirements notation 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Introduction 86 The Kerberos version 5 authentication service described in [RFC4120] 87 describes how a Key Distribution Service (KDC) provides 88 authentication to clients. The standard does not stipulate how a KDC 89 is managed and several "kadmin" servers have evolved. This document 90 describes the services required to administrate a KDC and the 91 underlying information model assumed by a kadmin-type service. 93 The information model is written in terms of "attributes" and 94 "services" or "interfaces" but the use of these particular words MUST 95 NOT be taken to imply any particular modeling paradigm so that 96 neither an object oriented model or an LDAP schema is intended. The 97 author has attempted to describe in natural language the intended 98 semantics and syntax of the components of the model. An LDAP schema 99 (for instance) based on this model will be more precise in the 100 expression of the syntax while preserving the semantics of this 101 model. 103 Implementations of this document MAY decide to change the names used 104 (eg principalName). If so an implementation MUST provide a name to 105 name mapping to this document. 107 3. How to interpret RFC2119 terms 109 This document describes an information model for kerberos 5 but does 110 not directly describe any mapping onto a particular schema- or 111 modelling language. Hence an implementation of this model consists 112 of a mapping to such a language - eg an LDAP or SQL schema. The 113 precise interpretation of terms from [RFC2119] therefore require some 114 extra explanation. The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL 115 NOT mean that an implementation MUST provide a feature but does not 116 mean that this feature MUST be REQUIRED by the implementation - eg an 117 attribute is available in an LDAP schema but marked as OPTIONAL. If 118 a feature must be implemented and REQUIRED this is made explicit in 119 this model. The term MAY, OPTIONAL and RECOMMENDED means that an 120 implementation MAY need to REQUIRE the feature due to the particular 121 nature of the schema/modelling language. In some cases this is 122 expressly forbidden by this model (feature X MUST NOT be REQUIRED by 123 an implementation). 125 Note that any implementation of this model SHOULD be published as an 126 RFC. 128 4. Acknowledgments 130 Love Hoernquist-Aestrand for important contributions. 132 5. Information model demarcation 134 The information model specified in the next chapter describes 135 objects, properties of those objects and relations between those 136 objects. These elements comprise an abstract view of the data 137 represented in a KDC. It is important to understand that the 138 information model is not a schema. In particular the way objects are 139 compared for equality beyond that which is implied by the 140 specification of a syntax is not part of this specification. Nor is 141 ordering specified between elements of a particular syntax. 143 Further work on Kerberos will undoubtedly prompt updates to this 144 information model to reflect changes in the functions performed by 145 the KDC. Such extensions to the information model MUST always use a 146 normative reference to the relevant RFCs detailing the change in KDC 147 function. 149 6. Information model specification 151 6.1. Principal 153 The fundamental entity stored in a KDC is the principal. The 154 principal is associated to keys and generalizes the "user" concept. 155 The principal MUST be implemented in full and MUST NOT be optional in 156 an implementation 158 6.1.1. Principal: Attributes 160 6.1.1.1. principalName 162 The principalName MUST uniquely identify the principal within the 163 administrative context of the KDC. The type of the principalName is 164 not described in this document. It is a unique identifier and can be 165 viewed as an opaque byte string which can be compared for equality. 166 The attribute SHOULD be single valued. If an implementation supports 167 multiple values it MUST treat one of the values as special and allow 168 it to be fetched as if it was a single value. 170 6.1.1.2. principalNotUsedBefore 172 The principal may not be used before this date. The syntax of the 173 attribute MUST be semantically equivalent with the standard ISO date 174 format. The attribute MUST be single valued. 176 6.1.1.3. principalNotUsedAfter 178 The principal may not be used after this date. The syntax of the 179 attribute MUST be semantically equivalent with the standard ISO date 180 format. The attribute MUST be single valued. 182 6.1.1.4. principalIsDisabled 184 A boolean attribute used to (temporarily) disable a principal. The 185 attribute MUST default to false. 187 6.1.1.5. principalAliases 189 This multivalued attribute contains an unordered set of aliases for 190 the principal. Each alias SHOULD be unique within the administrative 191 domain represented by the KDC. The syntax of an alias is an opaque 192 identifier which can be compared for equality. 194 6.1.1.6. principalNumberOfFailedAuthenticationAttempts 196 This single valued integer attribute contains a count of the number 197 of times an authentication attempt was unsuccessful for this 198 principal. Implementations SHOULD NOT allow this counter to be 199 reset. 201 6.1.1.7. principalLastFailedAuthentication 203 This single valued attribute contains the time and date for the last 204 failed authentication attempt for this principal. 206 6.1.1.8. principalLastSuccessfulAuthentication 208 This single valued attribute contains the time and date for the last 209 successful authentication attempt for this principal. 211 6.1.1.9. principalLastCredentialChange 213 This single valued attribute contains the time and date for the last 214 successful change of credential (eg password) this principal. 216 6.1.1.10. principalCreateTime 218 This single valued attribute contains the time and date when this 219 principal was created 221 6.1.1.11. principalModdifyTime 223 This single valued attribute contains the time and date when this 224 principal was modified excluding credentials change. 226 6.1.1.12. principalMaximumTicketLifetime 228 This single valued attribute contains the delta time in seconds 229 representing the maximum ticket lifetime for tickets issued for this 230 principal. 232 6.1.1.13. principalMaximumRenewableTicketLifetime 234 This single valued attribute contains the delta time in seconds 235 representing the maximum amount of time a ticket may be renewed for. 237 6.1.2. Principal: Associations 239 Each principal MAY be associated with 1 or more KeySet and MAY be 240 associated with 1 or more Policies. The KeySet is represented as an 241 object in this model since it has attributes associated with it (the 242 key version number). In typical situations the principal is 243 associated with exactly 1 KeySet but implementations MUST NOT assume 244 this case, i.e an implemenation of this standard (e.g an LDAP schema) 245 MUST be able to handle the general case of multiple KeySet associated 246 with each principal. 248 6.1.3. Principal: Remarks 250 Traditionally a principal consists of a local-part and a realm 251 denoted in string form by local-part@REALM. The realm concept is 252 used to provide administrative boundaries and together with cross- 253 realm authentication provides scalability to Kerberos 5. However the 254 realm is not central to an administrative information model. For 255 instance the initialization or creation of a realm is equivalent to 256 creating a specific set of principals (krbtgt@REALM, etc) which is 257 covered by the model and services described in this document. A 258 realm is typically associated with policy covering (for instance) 259 keying and password management. The management of such policy and 260 their association to realms is beyond the scope of this document. 262 6.2. KeySet 264 A KeySet is a set of keys associated with exactly one principal. 265 This object and its associations MUST NOT be REQUIRED by an 266 implementation. It is expected that most implementations of this 267 standard will use the set/change password protocol for all aspects of 268 key management [I-D.ietf-krb-wg-kerberos-set-passwd]. This 269 information model only includes these objects for the sake of 270 completenes. 272 6.2.1. KeySet: Attributes 274 6.2.1.1. keySetVersionNumber 276 This is traditionally called the key version number (kvno). This is 277 a single valued attribute containing a positive integer. 279 6.2.2. KeySet: Associations 281 To each KeySet MUST be associated a set of 1 or more Keys. 283 6.2.3. KeySet: Remarks 285 The reason for separating the KeySet from the Principal is security. 286 The security of Kerberos 5 depends absolutely on the security of the 287 keys stored in the KDC. The KeySet type is provided to make this 288 clear and to make separation of keys from other parts of the model 289 clear. 291 Implementations of this standard (eg an LDAP schema) MUST make a 292 clear separation between the representation of KeySet from other 293 information objects. 295 6.3. Key 297 Implementations of this model MUST NOT REQUIRE keys to be 298 represented. 300 6.3.1. Key: Attributes 302 6.3.1.1. keyEncryptionType 304 The enctype SHOULD be represented as an enumeration of the enctypes 305 supported by the KDC. 307 6.3.1.2. keyValue 309 The binary representation of the key data. This MUST be a single 310 valued octet string. 312 6.3.1.3. keySaltValue 314 The binary representation of the key salt. This MUST be a single 315 valued octet string. 317 6.3.1.4. keyStringToKeyParameter 319 This MUST be a single valued octet string representing an opaque 320 parameter associated with the enctype. 322 6.3.1.5. keyNotUsedAfter 324 This key MUST NOT be used after this date. The syntax of the 325 attribute MUST be semantically equivalent with the standard ISO date 326 format. This MUST be a single-valued attribute. 328 6.3.1.6. keyNotUsedBefore 330 This key MUST NOT be used before this date. The syntax of the 331 attribute MUST be semantically equivalent with the standard ISO date 332 format. This MUST be a single-valued attribute. 334 6.3.1.7. keyIsDisabled 336 This is a boolean attribute which must be set to false by default. 337 If this attribute is true the key MUST NOT be used. This is used to 338 temporarily disable a key. 340 6.3.2. Key: Associations 342 None 344 6.3.3. Key: Remarks 346 The security of the keys is an absolute requirement for the operation 347 of Kerberos 5. If keys are implemented adequate protection from 348 unauthorized modification and disclosure MUST be available and 349 REQUIRED by the implementation. 351 6.4. Policy 353 Implementations SHOULD implement policy but MAY allow them to be 354 OPTIONAL. The Policy should be thought of as a 'typed hole'. i.e an 355 opaque binary value paired with an identifier of type of data 356 contained in the binary value. Both attributes (type and value) must 357 be present. 359 6.4.1. Policy: Attributes 361 6.4.1.1. policyIdentifier 363 The policyIdentifier MUST be unique within the local administrative 364 context and MUST be globally unique. Possible types of identifiers 365 include: 367 An Object Identifier (OID) 369 A URN 371 A UUID 373 The use of OIDs is recommended for this purpose. 375 6.4.1.2. policyIsCritical 377 This boolean attribute indicates that the KDC MUST be able to 378 correctly interpret and apply this policy for the key to be used. 380 6.4.1.3. policyContent 382 This is an optional single opaque binary value used to store a 383 representation of the policy. In general a policy cannot be fully 384 expressed using attribute-value pairs. The policyContent is OPTIONAL 385 in the sense that an implementation MAY use it to store an opaque 386 value for those policy-types which are not directly representable in 387 that implementation. 389 6.4.1.4. policyUse 391 This is an optional single enumerated string value used to describe 392 the applicability of the policy. Implementations SHOULD provide this 393 attribute and MUST (if the attribute is implemented) describe the 394 enumerated set of possible values. 396 6.4.2. Mandatory-to-implement Policy 398 All implementations MUST be able to represent the policies listed in 399 this section. Implementations are not required to use the same 400 underlying data-representation for the policyContent binary value but 401 SHOULD use the same OIDs as the policyIdentifier. 403 6.4.2.1. Password Quality Policy 405 Password quality policy controls the requirements placed by the KDC 406 on new passwords. This policy SHOULD be identified by the OID . 408 6.4.2.2. Password Management Policy 410 Password management policy controls how passwords are changed. This 411 policy SHOULD be identified by the OID . 413 6.4.2.3. Keying Policy 415 A keying policy specifies the association of enctypes with new 416 principals, i.e when a principal is created one of the possibly many 417 applicable keying policies determine the set of keys to associate 418 with the principal. In general the expression of a keying policy may 419 require a Turing-complete language. This policy SHOULD be identified 420 by the OID . 422 7. Implementation Scenarios 424 There are several ways to implement an administrative service for 425 Kerberos 5 based on this information model. In this section we list 426 a few of them. 428 7.1. LDAP backend to KDC 430 Given an LDAP schema implementation of this information model it 431 would be possible to build an administrative service by backending 432 the KDC to a directory server where principals and keys are stored. 433 Using the security mechanisms available on the directory server keys 434 are protected from access by anyone apart from the KDC. 435 Administration of the principals, policy and other non-key data is 436 done through the directory server while the keys are modified using 437 the set/change password protocol 438 [I-D.ietf-krb-wg-kerberos-set-passwd]. 440 7.2. LDAP frontend to KDC 442 An alternative way to provide a directory interface to the KDC is to 443 implement an LDAP-frontend to the KDC which exposes all non-key 444 objects as entries and attributes. As in the example above all keys 445 are modified using the set/change password protocol 446 [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the 447 implementation would typically not use a traditional LDAP 448 implementation but treat LDAP as an access-protocol to data in the 449 native KDC database. 451 7.3. SOAP 453 Given an XML schema implementation of this information model it would 454 be possible to build a SOAP-interface to the KDC. This demonstrates 455 the value of creating an abstract information model which is mappable 456 to multiple schema representations. 458 8. Security Considerations 460 This document describes an abstract information model for Kerberos 5. 461 The Kerberos 5 protocol depends on the security of the keys stored in 462 the KDC. The model described here assumes that keys MUST NOT be 463 transported in the clear over the network and furthermore that keys 464 are treated as write-only attributes that SHALL only be modified 465 (using the administrative interface) by the change-password protocol 466 [I-D.ietf-krb-wg-kerberos-set-passwd]. 468 Exposing the object model of a KDC typically implies that objects can 469 be modified and/or deleted. In a KDC not all principals are created 470 equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM 471 effectively disables the EXAMPLE.COM realm. Hence access control is 472 paramount to the security of any implementation. This document does 473 not (at the time of writing - leifj) mandate access control. This 474 only implies that access control is beyond the scope of the standard 475 information model, i.e that access control may not be accessible via 476 any protocol based on this model. If access control objects is 477 exposed via an extension to this model the presence of access control 478 may in itself provide points of attack by giving away information 479 about principals with elevated rights etc. etc. 481 9. IANA Considerations 483 None 485 10. References 487 10.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, March 1997. 492 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 493 Kerberos Network Authentication Service (V5)", RFC 4120, 494 July 2005. 496 10.2. Informative References 498 [I-D.ietf-krb-wg-kerberos-set-passwd] 499 Williams, N., "Kerberos Set/Change Key/Password Protocol 500 Version 2", draft-ietf-krb-wg-kerberos-set-passwd-07 (work 501 in progress), September 2007. 503 Author's Address 505 Leif Johansson 506 Stockholm university 507 Avdelningen foer IT och Media 508 Stockholm SE-106 91 510 Email: leifj@it.su.se 511 URI: http://people.su.se/~leifj/ 513 Full Copyright Statement 515 Copyright (C) The IETF Trust (2008). 517 This document is subject to the rights, licenses and restrictions 518 contained in BCP 78, and except as set forth therein, the authors 519 retain all their rights. 521 This document and the information contained herein are provided on an 522 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 523 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 524 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 525 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 526 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 527 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 529 Intellectual Property 531 The IETF takes no position regarding the validity or scope of any 532 Intellectual Property Rights or other rights that might be claimed to 533 pertain to the implementation or use of the technology described in 534 this document or the extent to which any license under such rights 535 might or might not be available; nor does it represent that it has 536 made any independent effort to identify any such rights. Information 537 on the procedures with respect to rights in RFC documents can be 538 found in BCP 78 and BCP 79. 540 Copies of IPR disclosures made to the IETF Secretariat and any 541 assurances of licenses to be made available, or the result of an 542 attempt made to obtain a general license or permission for the use of 543 such proprietary rights by implementers or users of this 544 specification can be obtained from the IETF on-line IPR repository at 545 http://www.ietf.org/ipr. 547 The IETF invites any interested party to bring to its attention any 548 copyrights, patents or patent applications, or other proprietary 549 rights that may cover technology that may be required to implement 550 this standard. Please address the information to the IETF at 551 ietf-ipr@ietf.org.