idnits 2.17.1 draft-ietf-krb-wg-kdc-model-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 -- 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 (March 8, 2009) is 5528 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 (==), 2 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 March 8, 2009 5 Expires: September 9, 2009 7 An information model for Kerberos version 5 8 draft-ietf-krb-wg-kdc-model-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 9, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes an information model for Kerberos version 5 47 from the point of view of an administrative service. There is no 48 standard for administrating a kerberos 5 KDC. This document 49 describes the services exposed by an administrative interface to a 50 KDC. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. How to interpret RFC2119 terms . . . . . . . . . . . . . . . . 5 57 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Information model demarcation . . . . . . . . . . . . . . . . 7 59 6. Information model specification . . . . . . . . . . . . . . . 8 60 6.1. Principal . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6.1.1. Principal: Attributes . . . . . . . . . . . . . . . . 8 62 6.1.2. Principal: Associations . . . . . . . . . . . . . . . 10 63 6.1.3. Principal: Remarks . . . . . . . . . . . . . . . . . . 10 64 6.2. KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6.2.1. KeySet: Attributes . . . . . . . . . . . . . . . . . . 10 66 6.2.2. KeySet: Associations . . . . . . . . . . . . . . . . . 10 67 6.2.3. KeySet: Remarks . . . . . . . . . . . . . . . . . . . 11 68 6.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.3.1. Key: Attributes . . . . . . . . . . . . . . . . . . . 11 70 6.3.2. Key: Associations . . . . . . . . . . . . . . . . . . 12 71 6.3.3. Key: Remarks . . . . . . . . . . . . . . . . . . . . . 12 72 6.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 6.4.1. Policy: Attributes . . . . . . . . . . . . . . . . . . 12 74 6.4.2. Mandatory-to-implement Policy . . . . . . . . . . . . 13 75 7. Implementation Scenarios . . . . . . . . . . . . . . . . . . . 14 76 7.1. LDAP backend to KDC . . . . . . . . . . . . . . . . . . . 14 77 7.2. LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 14 78 7.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.4. Netconf . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Introduction 95 The Kerberos version 5 authentication service described in [RFC4120] 96 describes how a Key Distribution Service (KDC) provides 97 authentication to clients. The standard does not stipulate how a KDC 98 is managed and several "kadmin" servers have evolved. This document 99 describes the services required to administrate a KDC and the 100 underlying information model assumed by a kadmin-type service. 102 The information model is written in terms of "attributes" and 103 "services" or "interfaces" but the use of these particular words MUST 104 NOT be taken to imply any particular modeling paradigm so that 105 neither an object oriented model or an LDAP schema is intended. The 106 author has attempted to describe in natural language the intended 107 semantics and syntax of the components of the model. An LDAP schema 108 (for instance) based on this model will be more precise in the 109 expression of the syntax while preserving the semantics of this 110 model. 112 Implementations of this document MAY decide to change the names used 113 (eg principalName). If so an implementation MUST provide a name to 114 name mapping to this document. 116 3. How to interpret RFC2119 terms 118 This document describes an information model for kerberos 5 but does 119 not directly describe any mapping onto a particular schema- or 120 modelling language. Hence an implementation of this model consists 121 of a mapping to such a language - eg an LDAP or SQL schema. The 122 precise interpretation of terms from [RFC2119] therefore require some 123 extra explanation. The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL 124 NOT mean that an implementation MUST provide a feature but does not 125 mean that this feature MUST be REQUIRED by the implementation - eg an 126 attribute is available in an LDAP schema but marked as OPTIONAL. If 127 a feature must be implemented and REQUIRED this is made explicit in 128 this model. The term MAY, OPTIONAL and RECOMMENDED means that an 129 implementation MAY need to REQUIRE the feature due to the particular 130 nature of the schema/modelling language. In some cases this is 131 expressly forbidden by this model (feature X MUST NOT be REQUIRED by 132 an implementation). 134 Note that any implementation of this model SHOULD be published as an 135 RFC. 137 4. Acknowledgments 139 Love Hoernquist-Aestrand for important contributions. 141 5. Information model demarcation 143 The information model specified in the next chapter describes 144 objects, properties of those objects and relations between those 145 objects. These elements comprise an abstract view of the data 146 represented in a KDC. It is important to understand that the 147 information model is not a schema. In particular the way objects are 148 compared for equality beyond that which is implied by the 149 specification of a syntax is not part of this specification. Nor is 150 ordering specified between elements of a particular syntax. 152 Further work on Kerberos will undoubtedly prompt updates to this 153 information model to reflect changes in the functions performed by 154 the KDC. Such extensions to the information model MUST always use a 155 normative reference to the relevant RFCs detailing the change in KDC 156 function. 158 6. Information model specification 160 6.1. Principal 162 The fundamental entity stored in a KDC is the principal. The 163 principal is associated to keys and generalizes the "user" concept. 164 The principal MUST be implemented in full and MUST NOT be optional in 165 an implementation 167 6.1.1. Principal: Attributes 169 6.1.1.1. principalName 171 The principalName MUST uniquely identify the principal within the 172 administrative context of the KDC. The type of the principalName is 173 not described in this document. It is a unique identifier and can be 174 viewed as an opaque byte string which can be compared for equality. 176 The attribute MAY be multivalued if the implmementation supports 177 aliases. In that case one of the principalName values MUST be 178 designated the canonical principalName and if the implementation 179 supports enctypes which require salt then one of the values of 180 principalName MUST be designated as the canonical salting 181 principalName. 183 6.1.1.2. principalNotUsedBefore 185 The principal may not be used before this date. The syntax of the 186 attribute MUST be semantically equivalent with the standard ISO date 187 format. The attribute MUST be single valued. 189 6.1.1.3. principalNotUsedAfter 191 The principal may not be used after this date. The syntax of the 192 attribute MUST be semantically equivalent with the standard ISO date 193 format. The attribute MUST be single valued. 195 6.1.1.4. principalIsDisabled 197 A boolean attribute used to (temporarily) disable a principal. The 198 attribute MUST default to false. 200 6.1.1.5. principalNumberOfFailedAuthenticationAttempts 202 This single valued integer attribute contains a count of the number 203 of times an authentication attempt was unsuccessful for this 204 principal. Implementations SHOULD NOT allow this counter to be 205 reset. 207 6.1.1.6. principalLastFailedAuthentication 209 This single valued attribute contains the time and date for the last 210 failed authentication attempt for this principal. 212 6.1.1.7. principalLastSuccessfulAuthentication 214 This single valued attribute contains the time and date for the last 215 successful authentication attempt for this principal. 217 6.1.1.8. principalLastCredentialChangeTime 219 This single valued attribute contains the time and date for the last 220 successful change of credential (eg password or private key) 221 associated with this principal. 223 6.1.1.9. principalCreateTime 225 This single valued attribute contains the time and date when this 226 principal was created 228 6.1.1.10. principalModifyTime 230 This single valued attribute contains the time and date when this 231 principal was modified excluding credentials change. 233 6.1.1.11. principalMaximumTicketLifetime 235 This single valued attribute contains the delta time in seconds 236 representing the maximum ticket lifetime for tickets issued for this 237 principal. 239 6.1.1.12. principalMaximumRenewableTicketLifetime 241 This single valued attribute contains the delta time in seconds 242 representing the maximum amount of time a ticket may be renewed for. 244 6.1.1.13. principalAllowedEnctype 246 This optional multi valued attribute lists the enctypes allowed for 247 this principal. If empty or absent any enctype supported by the 248 implementation is allowed for this principal. 250 Implementations MAY choose to use policy objects in order to 251 represent more complex decision mechanisms. 253 6.1.2. Principal: Associations 255 Each principal MAY be associated with 0 or more KeySet and MAY be 256 associated with 0 or more Policies. The KeySet is represented as an 257 object in this model since it has attributes associated with it (the 258 key version number). In typical situations the principal is 259 associated with exactly 1 KeySet but implementations MUST NOT assume 260 this case, i.e an implementation of this standard (e.g an LDAP 261 schema) MUST be able to handle the general case of multiple KeySet 262 associated with each principal. 264 6.1.3. Principal: Remarks 266 Traditionally a principal consists of a local-part and a realm 267 denoted in string form by local-part@REALM. The realm concept is 268 used to provide administrative boundaries and together with cross- 269 realm authentication provides scalability to Kerberos 5. However the 270 realm is not central to an administrative information model. For 271 instance the initialization or creation of a realm is equivalent to 272 creating a specific set of principals (krbtgt@REALM, etc) which is 273 covered by the model and services described in this document. A 274 realm is typically associated with policy covering (for instance) 275 keying and password management. The management of such policy and 276 their association to realms is beyond the scope of this document. 278 6.2. KeySet 280 A KeySet is a set of keys associated with exactly one principal. 281 This object and its associations MUST NOT be REQUIRED by an 282 implementation. It is expected that most implementations of this 283 standard will use the set/change password protocol for all aspects of 284 key management [I-D.ietf-krb-wg-kerberos-set-passwd]. This 285 information model only includes these objects for the sake of 286 completenes. 288 6.2.1. KeySet: Attributes 290 6.2.1.1. keySetVersionNumber 292 This is traditionally called the key version number (kvno). This is 293 a single valued attribute containing a positive integer. 295 6.2.2. KeySet: Associations 297 To each KeySet MUST be associated a set of 1 or more Keys. 299 6.2.3. KeySet: Remarks 301 The reason for separating the KeySet from the Principal is security. 302 The security of Kerberos 5 depends absolutely on the security of the 303 keys stored in the KDC. The KeySet type is provided to make this 304 clear and to make separation of keys from other parts of the model 305 clear. 307 Implementations of this standard (eg an LDAP schema) MUST make a 308 clear separation between the representation of KeySet from other 309 information objects. 311 6.3. Key 313 Implementations of this model MUST NOT REQUIRE keys to be 314 represented. 316 6.3.1. Key: Attributes 318 6.3.1.1. keyEncryptionType 320 The enctype SHOULD be represented as an enumeration of the enctypes 321 supported by the KDC. 323 6.3.1.2. keyValue 325 The binary representation of the key data. This MUST be a single 326 valued octet string. 328 6.3.1.3. keySaltValue 330 The binary representation of the key salt. This MUST be a single 331 valued octet string. 333 6.3.1.4. keyStringToKeyParameter 335 This MUST be a single valued octet string representing an opaque 336 parameter associated with the enctype. 338 6.3.1.5. keyNotUsedAfter 340 This key MUST NOT be used after this date. The syntax of the 341 attribute MUST be semantically equivalent with the standard ISO date 342 format. This MUST be a single-valued attribute. 344 6.3.1.6. keyNotUsedBefore 346 This key MUST NOT be used before this date. The syntax of the 347 attribute MUST be semantically equivalent with the standard ISO date 348 format. This MUST be a single-valued attribute. 350 6.3.1.7. keyIsDisabled 352 This is a boolean attribute which must be set to false by default. 353 If this attribute is true the key MUST NOT be used. This is used to 354 temporarily disable a key. 356 6.3.2. Key: Associations 358 None 360 6.3.3. Key: Remarks 362 The security of the keys is an absolute requirement for the operation 363 of Kerberos 5. If keys are implemented adequate protection from 364 unauthorized modification and disclosure MUST be available and 365 REQUIRED by the implementation. 367 6.4. Policy 369 Implementations SHOULD implement policy but MAY allow them to be 370 OPTIONAL. The Policy should be thought of as a 'typed hole'. i.e an 371 opaque binary value paired with an identifier of type of data 372 contained in the binary value. Both attributes (type and value) must 373 be present. 375 6.4.1. Policy: Attributes 377 6.4.1.1. policyIdentifier 379 The policyIdentifier MUST be unique within the local administrative 380 context and MUST be globally unique. Possible types of identifiers 381 include: 383 An Object Identifier (OID) 385 A URN 387 A UUID 389 The use of OIDs is recommended for this purpose. 391 6.4.1.2. policyIsCritical 393 This boolean attribute indicates that the KDC MUST be able to 394 correctly interpret and apply this policy for the key to be used. 396 6.4.1.3. policyContent 398 This is an optional single opaque binary value used to store a 399 representation of the policy. In general a policy cannot be fully 400 expressed using attribute-value pairs. The policyContent is OPTIONAL 401 in the sense that an implementation MAY use it to store an opaque 402 value for those policy-types which are not directly representable in 403 that implementation. 405 6.4.1.4. policyUse 407 This is an optional single enumerated string value used to describe 408 the applicability of the policy. Implementations SHOULD provide this 409 attribute and MUST (if the attribute is implemented) describe the 410 enumerated set of possible values. 412 6.4.2. Mandatory-to-implement Policy 414 All implementations MUST be able to represent the policies listed in 415 this section. Implementations are not required to use the same 416 underlying data-representation for the policyContent binary value but 417 SHOULD use the same OIDs as the policyIdentifier. 419 6.4.2.1. Password Quality Policy 421 Password quality policy controls the requirements placed by the KDC 422 on new passwords. This policy SHOULD be identified by the OID . 424 6.4.2.2. Password Management Policy 426 Password management policy controls how passwords are changed. This 427 policy SHOULD be identified by the OID . 429 6.4.2.3. Keying Policy 431 A keying policy specifies the association of enctypes with new 432 principals, i.e when a principal is created one of the possibly many 433 applicable keying policies determine the set of keys to associate 434 with the principal. In general the expression of a keying policy may 435 require a Turing-complete language. This policy SHOULD be identified 436 by the OID . 438 7. Implementation Scenarios 440 There are several ways to implement an administrative service for 441 Kerberos 5 based on this information model. In this section we list 442 a few of them. 444 7.1. LDAP backend to KDC 446 Given an LDAP schema implementation of this information model it 447 would be possible to build an administrative service by backending 448 the KDC to a directory server where principals and keys are stored. 449 Using the security mechanisms available on the directory server keys 450 are protected from access by anyone apart from the KDC. 451 Administration of the principals, policy and other non-key data is 452 done through the directory server while the keys are modified using 453 the set/change password protocol 454 [I-D.ietf-krb-wg-kerberos-set-passwd]. 456 7.2. LDAP frontend to KDC 458 An alternative way to provide a directory interface to the KDC is to 459 implement an LDAP-frontend to the KDC which exposes all non-key 460 objects as entries and attributes. As in the example above all keys 461 are modified using the set/change password protocol 462 [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the 463 implementation would typically not use a traditional LDAP 464 implementation but treat LDAP as an access-protocol to data in the 465 native KDC database. 467 7.3. SOAP 469 Given an XML schema implementation of this information model it would 470 be possible to build a SOAP-interface to the KDC. This demonstrates 471 the value of creating an abstract information model which is mappable 472 to multiple schema representations. 474 7.4. Netconf 476 Given a YAML implementation of this information model it would be 477 possible to create a Netconf-based interface to the KDC in theory 478 enabling management of the KDC from standard network management 479 applications 481 8. Security Considerations 483 This document describes an abstract information model for Kerberos 5. 484 The Kerberos 5 protocol depends on the security of the keys stored in 485 the KDC. The model described here assumes that keys MUST NOT be 486 transported in the clear over the network and furthermore that keys 487 are treated as write-only attributes that SHALL only be modified 488 (using the administrative interface) by the change-password protocol 489 [I-D.ietf-krb-wg-kerberos-set-passwd]. 491 Exposing the object model of a KDC typically implies that objects can 492 be modified and/or deleted. In a KDC not all principals are created 493 equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM 494 effectively disables the EXAMPLE.COM realm. Hence access control is 495 paramount to the security of any implementation. This document does 496 not (at the time of writing - leifj) mandate access control. This 497 only implies that access control is beyond the scope of the standard 498 information model, i.e that access control may not be accessible via 499 any protocol based on this model. If access control objects is 500 exposed via an extension to this model the presence of access control 501 may in itself provide points of attack by giving away information 502 about principals with elevated rights etc. etc. 504 9. IANA Considerations 506 None 508 10. References 510 10.1. Normative References 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, March 1997. 515 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 516 Kerberos Network Authentication Service (V5)", RFC 4120, 517 July 2005. 519 10.2. Informative References 521 [I-D.ietf-krb-wg-kerberos-set-passwd] 522 Williams, N., "Kerberos Set/Change Key/Password Protocol 523 Version 2", draft-ietf-krb-wg-kerberos-set-passwd-07 (work 524 in progress), September 2007. 526 Author's Address 528 Leif Johansson 529 Stockholm university 530 Avdelningen foer IT och Media 531 Stockholm SE-106 91 533 Email: leifj@it.su.se 534 URI: http://people.su.se/~leifj/