idnits 2.17.1 draft-ietf-krb-wg-kdc-model-06.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 (October 19, 2009) is 5296 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KERBEROS WORKING GROUP Johansson 3 Internet-Draft SUNET 4 Intended status: Standards Track October 19, 2009 5 Expires: April 22, 2010 7 An information model for Kerberos version 5 8 draft-ietf-krb-wg-kdc-model-06 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 April 22, 2010. 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.2. KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 6.2.1. KeySet: Attributes . . . . . . . . . . . . . . . . . . 10 65 6.2.2. KeySet: Associations . . . . . . . . . . . . . . . . . 10 66 6.2.3. KeySet: Remarks . . . . . . . . . . . . . . . . . . . 10 67 6.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6.3.1. Key: Attributes . . . . . . . . . . . . . . . . . . . 11 69 6.3.2. Key: Associations . . . . . . . . . . . . . . . . . . 12 70 6.3.3. Key: Remarks . . . . . . . . . . . . . . . . . . . . . 12 71 6.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.4.1. Policy: Attributes . . . . . . . . . . . . . . . . . . 12 73 6.4.2. Mandatory-to-implement Policy . . . . . . . . . . . . 13 74 7. Implementation Scenarios . . . . . . . . . . . . . . . . . . . 14 75 7.1. LDAP backend to KDC . . . . . . . . . . . . . . . . . . . 14 76 7.2. LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 14 77 7.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.4. Netconf . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Requirements notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Introduction 94 The Kerberos version 5 authentication service described in [RFC4120] 95 describes how a Key Distribution Service (KDC) provides 96 authentication to clients. The standard does not stipulate how a KDC 97 is managed and several "kadmin" servers have evolved. This document 98 describes the services required to administrate a KDC and the 99 underlying information model assumed by a kadmin-type service. 101 The information model is written in terms of "attributes" and 102 "services" or "interfaces" but the use of these particular words MUST 103 NOT be taken to imply any particular modeling paradigm so that 104 neither an object oriented model or an LDAP schema is intended. The 105 author has attempted to describe in natural language the intended 106 semantics and syntax of the components of the model. An LDAP schema 107 (for instance) based on this model will be more precise in the 108 expression of the syntax while preserving the semantics of this 109 model. 111 Implementations of this document MAY decide to change the names used 112 (eg principalName). If so an implementation MUST provide a name to 113 name mapping to this document. 115 3. How to interpret RFC2119 terms 117 This document describes an information model for kerberos 5 but does 118 not directly describe any mapping onto a particular schema- or 119 modelling language. Hence an implementation of this model consists 120 of a mapping to such a language - eg an LDAP or SQL schema. The 121 precise interpretation of terms from [RFC2119] therefore require some 122 extra explanation. The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL 123 NOT mean that an implementation MUST provide a feature but does not 124 mean that this feature MUST be REQUIRED by the implementation - eg an 125 attribute is available in an LDAP schema but marked as OPTIONAL. If 126 a feature must be implemented and REQUIRED this is made explicit in 127 this model. The term MAY, OPTIONAL and RECOMMENDED means that an 128 implementation MAY need to REQUIRE the feature due to the particular 129 nature of the schema/modelling language. In some cases this is 130 expressly forbidden by this model (feature X MUST NOT be REQUIRED by 131 an implementation). 133 Note that any implementation of this model SHOULD be published as an 134 RFC. 136 4. Acknowledgments 138 Love Hoernquist-Aestrand for important contributions. 140 5. Information model demarcation 142 The information model specified in the next chapter describes 143 objects, properties of those objects and relations between those 144 objects. These elements comprise an abstract view of the data 145 represented in a KDC. It is important to understand that the 146 information model is not a schema. In particular the way objects are 147 compared for equality beyond that which is implied by the 148 specification of a syntax is not part of this specification. Nor is 149 ordering specified between elements of a particular syntax. 151 Further work on Kerberos will undoubtedly prompt updates to this 152 information model to reflect changes in the functions performed by 153 the KDC. Such extensions to the information model MUST always use a 154 normative reference to the relevant RFCs detailing the change in KDC 155 function. 157 This model describes a number of elements related to password policy 158 management. Not all of the elements in this model are unique to 159 Kerberos; an LDAP implementation of this model should incorporate 160 existing LDAP schema where functional overlap exists, rather than 161 defining additional Kerberos-specific elements. 163 6. Information model specification 165 6.1. Principal 167 The fundamental entity stored in a KDC is the principal. The 168 principal is associated to keys and generalizes the "user" concept. 169 The principal MUST be implemented in full and MUST NOT be optional in 170 an implementation 172 6.1.1. Principal: Attributes 174 6.1.1.1. principalName 176 The principalName MUST uniquely identify the principal within the 177 administrative context of the KDC. The type of the principalName is 178 not described in this document. It is a unique identifier and can be 179 viewed as an opaque byte string which can be compared for equality. 181 The attribute MAY be multivalued if the implmementation supports 182 aliases. In that case exactly one of the principalName values MUST 183 be designated the canonical principalName and if the implementation 184 supports enctypes which require salt then exactly one of the values 185 of principalName MUST be designated as the canonical salting 186 principalName. 188 6.1.1.2. principalNotUsedBefore 190 The principal may not be used before this date. The syntax of the 191 attribute MUST be semantically equivalent with the standard ISO date 192 format. The attribute MUST be single valued. 194 6.1.1.3. principalNotUsedAfter 196 The principal may not be used after this date. The syntax of the 197 attribute MUST be semantically equivalent with the standard ISO date 198 format. The attribute MUST be single valued. 200 6.1.1.4. principalIsDisabled 202 A boolean attribute used to (temporarily) disable a principal. The 203 attribute SHOULD default to false. 205 6.1.1.5. principalNumberOfFailedAuthenticationAttempts 207 This single valued integer attribute contains a count of the number 208 of times an authentication attempt was unsuccessful for this 209 principal. Implementations SHOULD NOT allow this counter to be 210 reset. 212 6.1.1.6. principalLastFailedAuthentication 214 This single valued attribute contains the time and date for the last 215 failed authentication attempt for this principal. 217 6.1.1.7. principalLastSuccessfulAuthentication 219 This single valued attribute contains the time and date for the last 220 successful authentication attempt for this principal. 222 6.1.1.8. principalLastCredentialChangeTime 224 This single valued attribute contains the time and date for the last 225 successful change of credential (eg password or private key) 226 associated with this principal. 228 6.1.1.9. principalCreateTime 230 This single valued attribute contains the time and date when this 231 principal was created 233 6.1.1.10. principalModifyTime 235 This single valued attribute contains the time and date when this 236 principal was modified excluding credentials change. 238 6.1.1.11. principalMaximumTicketLifetime 240 This single valued attribute contains the delta time in seconds 241 representing the maximum ticket lifetime for tickets issued for this 242 principal. 244 6.1.1.12. principalMaximumRenewableTicketLifetime 246 This single valued attribute contains the delta time in seconds 247 representing the maximum amount of time a ticket may be renewed for. 249 6.1.1.13. principalAllowedEnctype 251 This optional multi valued attribute lists the enctypes allowed for 252 this principal. If empty or absent any enctype supported by the 253 implementation is allowed for this principal. 255 Implementations MAY choose to use policy objects in order to 256 represent more complex decision mechanisms. 258 6.1.1.14. principalRealm 260 This is a multi valued attribute listing the realms in which this 261 principal exists using the string representation of the realm 262 name(s). 264 6.1.2. Principal: Associations 266 Each principal MAY be associated with 0 or more KeySet and MAY be 267 associated with 0 or more Policies. The KeySet is represented as an 268 object in this model since it has attributes associated with it (the 269 key version number). In typical situations the principal is 270 associated with exactly 1 KeySet but implementations MUST NOT assume 271 this case, i.e an implementation of this standard (e.g an LDAP 272 schema) MUST be able to handle the general case of multiple KeySet 273 associated with each principal. 275 6.2. KeySet 277 A KeySet is a set of keys associated with exactly one principal. 278 This object and its associations MUST NOT be REQUIRED by an 279 implementation. It is expected that most implementations of this 280 standard will use the set/change password protocol for all aspects of 281 key management [I-D.ietf-krb-wg-kerberos-set-passwd]. This 282 information model only includes these objects for the sake of 283 completenes. 285 6.2.1. KeySet: Attributes 287 6.2.1.1. keySetVersionNumber 289 This is traditionally called the key version number (kvno). This is 290 a single valued attribute containing a positive integer. 292 6.2.2. KeySet: Associations 294 To each KeySet MUST be associated a set of 1 or more Keys. 296 6.2.3. KeySet: Remarks 298 The reason for separating the KeySet from the Principal is security. 299 The security of Kerberos 5 depends absolutely on the security of the 300 keys stored in the KDC. The KeySet type is provided to make this 301 clear and to make separation of keys from other parts of the model 302 clear. 304 Implementations of this standard (eg an LDAP schema) MUST make a 305 clear separation between the representation of KeySet from other 306 information objects. 308 6.3. Key 310 Implementations of this model MUST NOT REQUIRE keys to be 311 represented. 313 6.3.1. Key: Attributes 315 6.3.1.1. keyEncryptionType 317 The enctype SHOULD be represented as an enumeration of the enctypes 318 supported by the KDC. 320 6.3.1.2. keyValue 322 The binary representation of the key data. This MUST be a single 323 valued octet string. 325 6.3.1.3. keySaltValue 327 The binary representation of the key salt. This MUST be a single 328 valued octet string. 330 6.3.1.4. keyStringToKeyParameter 332 This MUST be a single valued octet string representing an opaque 333 parameter associated with the enctype. 335 6.3.1.5. keyNotUsedAfter 337 This key MUST NOT be used after this date. The syntax of the 338 attribute MUST be semantically equivalent with the standard ISO date 339 format. This MUST be a single-valued attribute. 341 6.3.1.6. keyNotUsedBefore 343 This key MUST NOT be used before this date. The syntax of the 344 attribute MUST be semantically equivalent with the standard ISO date 345 format. This MUST be a single-valued attribute. 347 6.3.1.7. keyIsDisabled 349 This is a boolean attribute which SHOULD be set to false by default. 350 If this attribute is true the key MUST NOT be used. This is used to 351 temporarily disable a key. 353 6.3.2. Key: Associations 355 None 357 6.3.3. Key: Remarks 359 The security of the keys is an absolute requirement for the operation 360 of Kerberos 5. If keys are implemented adequate protection from 361 unauthorized modification and disclosure MUST be available and 362 REQUIRED by the implementation. 364 6.4. Policy 366 Implementations SHOULD implement policy but MAY allow them to be 367 OPTIONAL. The Policy should be thought of as a 'typed hole'. i.e an 368 opaque binary value paired with an identifier of type of data 369 contained in the binary value. Both attributes (type and value) must 370 be present. 372 6.4.1. Policy: Attributes 374 6.4.1.1. policyIdentifier 376 The policyIdentifier MUST be unique within the local administrative 377 context and MUST be globally unique. Possible types of identifiers 378 include: 380 An Object Identifier (OID) 382 A URI 384 A UUID 386 The use of OIDs is RECOMMENDED for this purpose. 388 6.4.1.2. policyIsCritical 390 This boolean attribute indicates that the KDC MUST be able to 391 correctly interpret and apply this policy for the key to be used. 393 6.4.1.3. policyContent 395 This is an optional single opaque binary value used to store a 396 representation of the policy. In general a policy cannot be fully 397 expressed using attribute-value pairs. The policyContent is OPTIONAL 398 in the sense that an implementation MAY use it to store an opaque 399 value for those policy-types which are not directly representable in 400 that implementation. 402 6.4.1.4. policyUse 404 This is an optional single enumerated string value used to describe 405 the applicability of the policy. Implementations SHOULD provide this 406 attribute and MUST (if the attribute is implemented) describe the 407 enumerated set of possible values. 409 6.4.2. Mandatory-to-implement Policy 411 All implementations MUST be able to represent the policies listed in 412 this section. Implementations are not required to use the same 413 underlying data-representation for the policyContent binary value but 414 SHOULD use the same OIDs as the policyIdentifier. In general the 415 expression of policy may require a Turing-complete language. This 416 specification does not attempt to model policy expression language. 418 6.4.2.1. Password Quality Policy 420 Password quality policy controls the requirements placed by the KDC 421 on new passwords. This policy SHOULD be identified by the OID 422 .1. 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 .2. 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. This policy SHOULD be identified by the OID 435 .3. 437 6.4.2.4. Ticket Flag Policy 439 A ticket flag policy specifies the ticket flags allowed for tickets 440 issued for a principal. This policy SHOULD be identified by the OID 441 .4. 443 7. Implementation Scenarios 445 There are several ways to implement an administrative service for 446 Kerberos 5 based on this information model. In this section we list 447 a few of them. 449 7.1. LDAP backend to KDC 451 Given an LDAP schema implementation of this information model it 452 would be possible to build an administrative service by backending 453 the KDC to a directory server where principals and keys are stored. 454 Using the security mechanisms available on the directory server keys 455 are protected from access by anyone apart from the KDC. 456 Administration of the principals, policy and other non-key data is 457 done through the directory server while the keys are modified using 458 the set/change password protocol 459 [I-D.ietf-krb-wg-kerberos-set-passwd]. 461 7.2. LDAP frontend to KDC 463 An alternative way to provide a directory interface to the KDC is to 464 implement an LDAP-frontend to the KDC which exposes all non-key 465 objects as entries and attributes. As in the example above all keys 466 are modified using the set/change password protocol 467 [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the 468 implementation would typically not use a traditional LDAP 469 implementation but treat LDAP as an access-protocol to data in the 470 native KDC database. 472 7.3. SOAP 474 Given an XML schema implementation of this information model it would 475 be possible to build a SOAP-interface to the KDC. This demonstrates 476 the value of creating an abstract information model which is mappable 477 to multiple schema representations. 479 7.4. Netconf 481 Given a YAML implementation of this information model it would be 482 possible to create a Netconf-based interface to the KDC in theory 483 enabling management of the KDC from standard network management 484 applications 486 8. Security Considerations 488 This document describes an abstract information model for Kerberos 5. 489 The Kerberos 5 protocol depends on the security of the keys stored in 490 the KDC. The model described here assumes that keys MUST NOT be 491 transported in the clear over the network and furthermore that keys 492 are treated as write-only attributes that SHALL only be modified 493 (using the administrative interface) by the change-password protocol 494 [I-D.ietf-krb-wg-kerberos-set-passwd]. 496 Exposing the object model of a KDC typically implies that objects can 497 be modified and/or deleted. In a KDC not all principals are created 498 equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM 499 effectively disables the EXAMPLE.COM realm. Hence access control is 500 paramount to the security of any implementation. This document does 501 not (at the time of writing - leifj) mandate access control. This 502 only implies that access control is beyond the scope of the standard 503 information model, i.e that access control may not be accessible via 504 any protocol based on this model. If access control objects is 505 exposed via an extension to this model the presence of access control 506 may in itself provide points of attack by giving away information 507 about principals with elevated rights etc. etc. 509 9. IANA Considerations 511 This document requires the allocation of several OIDs marked in 512 the text. 514 10. References 516 10.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 522 Kerberos Network Authentication Service (V5)", RFC 4120, 523 July 2005. 525 10.2. Informative References 527 [I-D.ietf-krb-wg-kerberos-set-passwd] 528 Williams, N., "Kerberos Set/Change Key/Password Protocol 529 Version 2", draft-ietf-krb-wg-kerberos-set-passwd-08 (work 530 in progress), November 2008. 532 Author's Address 534 Leif Johansson 535 Swedish University Network 536 Thulegatan 11 537 Stockholm 539 Email: leifj@sunet.se 540 URI: http://www.sunet.se