idnits 2.17.1 draft-ietf-krb-wg-kdc-model-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 7, 2010) is 5154 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 March 7, 2010 5 Expires: September 8, 2010 7 An information model for Kerberos version 5 8 draft-ietf-krb-wg-kdc-model-07 10 Abstract 12 This document describes an information model for Kerberos version 5 13 from the point of view of an administrative service. There is no 14 standard for administrating a kerberos 5 KDC. This document 15 describes the services exposed by an administrative interface to a 16 KDC. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 8, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. How to interpret RFC2119 terms . . . . . . . . . . . . . . . . 5 61 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Information model demarcation . . . . . . . . . . . . . . . . 7 63 6. Information model specification . . . . . . . . . . . . . . . 8 64 6.1. Principal . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.1.1. Principal: Attributes . . . . . . . . . . . . . . . . 8 66 6.1.2. Principal: Associations . . . . . . . . . . . . . . . 10 67 6.2. KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.2.1. KeySet: Attributes . . . . . . . . . . . . . . . . . . 10 69 6.2.2. KeySet: Associations . . . . . . . . . . . . . . . . . 10 70 6.2.3. KeySet: Remarks . . . . . . . . . . . . . . . . . . . 10 71 6.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6.3.1. Key: Attributes . . . . . . . . . . . . . . . . . . . 11 73 6.3.2. Key: Associations . . . . . . . . . . . . . . . . . . 12 74 6.3.3. Key: Remarks . . . . . . . . . . . . . . . . . . . . . 12 75 6.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.4.1. Policy: Attributes . . . . . . . . . . . . . . . . . . 12 77 6.4.2. Mandatory-to-implement Policy . . . . . . . . . . . . 13 78 7. Implementation Scenarios . . . . . . . . . . . . . . . . . . . 15 79 7.1. LDAP backend to KDC . . . . . . . . . . . . . . . . . . . 15 80 7.2. LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 15 81 7.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 7.4. Netconf . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 The Kerberos version 5 authentication service described in [RFC4120] 99 describes how a Key Distribution Service (KDC) provides 100 authentication to clients. The standard does not stipulate how a KDC 101 is managed and several "kadmin" servers have evolved. This document 102 describes the services required to administrate a KDC and the 103 underlying information model assumed by a kadmin-type service. 105 The information model is written in terms of "attributes" and 106 "services" or "interfaces" but the use of these particular words MUST 107 NOT be taken to imply any particular modeling paradigm so that 108 neither an object oriented model or an LDAP schema is intended. The 109 author has attempted to describe in natural language the intended 110 semantics and syntax of the components of the model. An LDAP schema 111 (for instance) based on this model will be more precise in the 112 expression of the syntax while preserving the semantics of this 113 model. 115 Implementations of this document MAY decide to change the names used 116 (eg principalName). If so an implementation MUST provide a name to 117 name mapping to this document. 119 3. How to interpret RFC2119 terms 121 This document describes an information model for kerberos 5 but does 122 not directly describe any mapping onto a particular schema- or 123 modelling language. Hence an implementation of this model consists 124 of a mapping to such a language - eg an LDAP or SQL schema. The 125 precise interpretation of terms from [RFC2119] therefore require some 126 extra explanation. The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL 127 NOT mean that an implementation MUST provide a feature but does not 128 mean that this feature MUST be REQUIRED by the implementation - eg an 129 attribute is available in an LDAP schema but marked as OPTIONAL. If 130 a feature must be implemented and REQUIRED this is made explicit in 131 this model. The term MAY, OPTIONAL and RECOMMENDED means that an 132 implementation MAY need to REQUIRE the feature due to the particular 133 nature of the schema/modelling language. In some cases this is 134 expressly forbidden by this model (feature X MUST NOT be REQUIRED by 135 an implementation). 137 Note that any implementation of this model SHOULD be published as an 138 RFC. 140 4. Acknowledgments 142 Love Hoernquist-Aestrand for important contributions. 144 5. Information model demarcation 146 The information model specified in the next chapter describes 147 objects, properties of those objects and relations between those 148 objects. These elements comprise an abstract view of the data 149 represented in a KDC. It is important to understand that the 150 information model is not a schema. In particular the way objects are 151 compared for equality beyond that which is implied by the 152 specification of a syntax is not part of this specification. Nor is 153 ordering specified between elements of a particular syntax. 155 Further work on Kerberos will undoubtedly prompt updates to this 156 information model to reflect changes in the functions performed by 157 the KDC. Such extensions to the information model MUST always use a 158 normative reference to the relevant RFCs detailing the change in KDC 159 function. 161 This model describes a number of elements related to password policy 162 management. Not all of the elements in this model are unique to 163 Kerberos; an LDAP implementation of this model should incorporate 164 existing LDAP schema where functional overlap exists, rather than 165 defining additional Kerberos-specific elements. 167 6. Information model specification 169 6.1. Principal 171 The fundamental entity stored in a KDC is the principal. The 172 principal is associated to keys and generalizes the "user" concept. 173 The principal MUST be implemented in full and MUST NOT be optional in 174 an implementation 176 6.1.1. Principal: Attributes 178 6.1.1.1. principalName 180 The principalName MUST uniquely identify the principal within the 181 administrative context of the KDC. The type of the principalName is 182 not described in this document. It is a unique identifier and can be 183 viewed as an opaque byte string which can be compared for equality. 185 The attribute MAY be multivalued if the implmementation supports 186 aliases. In that case exactly one of the principalName values MUST 187 be designated the canonical principalName and if the implementation 188 supports enctypes which require salt then exactly one of the values 189 of principalName MUST be designated as the canonical salting 190 principalName. 192 6.1.1.2. principalNotUsedBefore 194 The principal may not be used before this date. The syntax of the 195 attribute MUST be semantically equivalent with the standard ISO date 196 format. The attribute MUST be single valued. 198 6.1.1.3. principalNotUsedAfter 200 The principal may not be used after this date. The syntax of the 201 attribute MUST be semantically equivalent with the standard ISO date 202 format. The attribute MUST be single valued. 204 6.1.1.4. principalIsDisabled 206 A boolean attribute used to (temporarily) disable a principal. The 207 attribute SHOULD default to false. 209 6.1.1.5. principalNumberOfFailedAuthenticationAttempts 211 This single valued integer attribute contains a count of the number 212 of times an authentication attempt was unsuccessful for this 213 principal. Implementations SHOULD NOT allow this counter to be 214 reset. 216 6.1.1.6. principalLastFailedAuthentication 218 This single valued attribute contains the time and date for the last 219 failed authentication attempt for this principal. 221 6.1.1.7. principalLastSuccessfulAuthentication 223 This single valued attribute contains the time and date for the last 224 successful authentication attempt for this principal. 226 6.1.1.8. principalLastCredentialChangeTime 228 This single valued attribute contains the time and date for the last 229 successful change of credential (eg password or private key) 230 associated with this principal. 232 6.1.1.9. principalCreateTime 234 This single valued attribute contains the time and date when this 235 principal was created 237 6.1.1.10. principalModifyTime 239 This single valued attribute contains the time and date when this 240 principal was modified excluding credentials change. 242 6.1.1.11. principalMaximumTicketLifetime 244 This single valued attribute contains the delta time in seconds 245 representing the maximum ticket lifetime for tickets issued for this 246 principal. 248 6.1.1.12. principalMaximumRenewableTicketLifetime 250 This single valued attribute contains the delta time in seconds 251 representing the maximum amount of time a ticket may be renewed for. 253 6.1.1.13. principalAllowedEnctype 255 This OPTIONAL multi valued attribute lists the enctypes allowed for 256 this principal. If empty or absent any enctype7 supported by the 257 implementation is allowed for this principal. 259 This attribute is intended as a policy attribute and restricts all 260 uses of enctypes including server, client and session keys. Data 261 models MAY choose to use policy objects in order to represent more 262 complex decision mechanisms. 264 6.1.1.14. principalRealm 266 This is a multi valued attribute listing the realms in which this 267 principal exists using the string representation of the realm 268 name(s). 270 6.1.2. Principal: Associations 272 Each principal MAY be associated with 0 or more KeySet and MAY be 273 associated with 0 or more Policies. The KeySet is represented as an 274 object in this model since it has attributes associated with it (the 275 key version number). In typical situations the principal is 276 associated with exactly 1 KeySet but implementations MUST NOT assume 277 this case, i.e an implementation of this standard (e.g an LDAP 278 schema) MUST be able to handle the general case of multiple KeySet 279 associated with each principal. 281 6.2. KeySet 283 A KeySet is a set of keys associated with exactly one principal. 284 This object and its associations MUST NOT be REQUIRED by a data- 285 model. It is expected that most Kerberos implementations will use 286 the set/change password protocol for all aspects of key management 287 [I-D.ietf-krb-wg-kerberos-set-passwd]. This information model only 288 includes these objects for the sake of completenes. 290 If a server supports an enctype that enctype must be present in at 291 least one key for the principal in question. 293 6.2.1. KeySet: Attributes 295 6.2.1.1. keySetVersionNumber 297 This is traditionally called the key version number (kvno). This is 298 a single valued attribute containing a positive integer. 300 6.2.2. KeySet: Associations 302 To each KeySet MUST be associated a set of 1 or more Keys. 304 6.2.3. KeySet: Remarks 306 The reason for separating the KeySet from the Principal is security. 307 The security of Kerberos 5 depends absolutely on the security of the 308 keys stored in the KDC. The KeySet type is provided to make this 309 clear and to make separation of keys from other parts of the model 310 clear. 312 Implementations of this standard (eg an LDAP schema) MUST make a 313 clear separation between the representation of KeySet from other 314 information objects. 316 6.3. Key 318 Implementations of this model MUST NOT REQUIRE keys to be 319 represented. 321 6.3.1. Key: Attributes 323 6.3.1.1. keyEncryptionType 325 The enctype SHOULD be represented as an enumeration of the enctypes 326 supported by the KDC using the string name of the enctype from 327 [RFC3961] 329 6.3.1.2. keyValue 331 The binary representation of the key data. This MUST be a single 332 valued octet string. 334 6.3.1.3. keySaltValue 336 The binary representation of the key salt. This MUST be a single 337 valued octet string. 339 6.3.1.4. keyStringToKeyParameter 341 This MUST be a single valued octet string representing an opaque 342 parameter associated with the enctype. 344 6.3.1.5. 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.6. keyNotUsedAfter 352 This key MUST NOT be used after this date. The syntax of the 353 attribute MUST be semantically equivalent with the standard ISO date 354 format. This MUST be a single-valued attribute. 356 6.3.1.7. keyNotUsedBefore 358 This key MUST NOT be used before this date. The syntax of the 359 attribute MUST be semantically equivalent with the standard ISO date 360 format. This MUST be a single-valued attribute. 362 6.3.1.8. keyIsDisabled 364 This is a boolean attribute which SHOULD be set to false by default. 365 If this attribute is true the key MUST NOT be used. This is used to 366 temporarily disable a key. 368 6.3.2. Key: Associations 370 None 372 6.3.3. Key: Remarks 374 The security of the keys is an absolute requirement for the operation 375 of Kerberos 5. If keys are implemented adequate protection from 376 unauthorized modification and disclosure MUST be available and 377 REQUIRED by the implementation. 379 6.4. Policy 381 Implementations SHOULD implement policy but MAY allow them to be 382 OPTIONAL. The Policy should be thought of as a 'typed hole'. i.e an 383 opaque binary value paired with an identifier of type of data 384 contained in the binary value. Both attributes (type and value) must 385 be present. 387 6.4.1. Policy: Attributes 389 6.4.1.1. policyIdentifier 391 The policyIdentifier MUST be unique within the local administrative 392 context and MUST be globally unique. Possible types of identifiers 393 include: 395 An Object Identifier (OID) 397 A URI 399 A UUID 401 The use of OIDs is RECOMMENDED for this purpose. 403 6.4.1.2. policyIsCritical 405 This boolean attribute indicates that the KDC MUST be able to 406 correctly interpret and apply this policy for the key to be used. 408 6.4.1.3. policyContent 410 This is an optional single opaque binary value used to store a 411 representation of the policy. In general a policy cannot be fully 412 expressed using attribute-value pairs. The policyContent is OPTIONAL 413 in the sense that an implementation MAY use it to store an opaque 414 value for those policy-types which are not directly representable in 415 that implementation. 417 6.4.1.4. policyUse 419 This is an optional single enumerated string value used to describe 420 the applicability of the policy. Implementations SHOULD provide this 421 attribute and MUST (if the attribute is implemented) describe the 422 enumerated set of possible values. 424 6.4.2. Mandatory-to-implement Policy 426 All implementations MUST be able to represent the policies listed in 427 this section. Implementations are not required to use the same 428 underlying data-representation for the policyContent binary value but 429 SHOULD use the same OIDs as the policyIdentifier. In general the 430 expression of policy may require a Turing-complete language. This 431 specification does not attempt to model policy expression language. 433 6.4.2.1. Password Quality Policy 435 Password quality policy controls the requirements placed by the KDC 436 on new passwords. This policy SHOULD be identified by the OID 437 .1. 439 6.4.2.2. Password Management Policy 441 Password management policy controls how passwords are changed. This 442 policy SHOULD be identified by the OID .2. 444 6.4.2.3. Keying Policy 446 A keying policy specifies the association of enctypes with new 447 principals, i.e when a principal is created one of the possibly many 448 applicable keying policies determine the set of keys to associate 449 with the principal. This policy SHOULD be identified by the OID 450 .3. 452 6.4.2.4. Ticket Flag Policy 454 A ticket flag policy specifies the ticket flags allowed for tickets 455 issued for a principal. This policy SHOULD be identified by the OID 456 .4. 458 7. Implementation Scenarios 460 There are several ways to implement an administrative service for 461 Kerberos 5 based on this information model. In this section we list 462 a few of them. 464 7.1. LDAP backend to KDC 466 Given an LDAP schema implementation of this information model it 467 would be possible to build an administrative service by backending 468 the KDC to a directory server where principals and keys are stored. 469 Using the security mechanisms available on the directory server keys 470 are protected from access by anyone apart from the KDC. 471 Administration of the principals, policy and other non-key data is 472 done through the directory server while the keys are modified using 473 the set/change password protocol 474 [I-D.ietf-krb-wg-kerberos-set-passwd]. 476 7.2. LDAP frontend to KDC 478 An alternative way to provide a directory interface to the KDC is to 479 implement an LDAP-frontend to the KDC which exposes all non-key 480 objects as entries and attributes. As in the example above all keys 481 are modified using the set/change password protocol 482 [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the 483 implementation would typically not use a traditional LDAP 484 implementation but treat LDAP as an access-protocol to data in the 485 native KDC database. 487 7.3. SOAP 489 Given an XML schema implementation of this information model it would 490 be possible to build a SOAP-interface to the KDC. This demonstrates 491 the value of creating an abstract information model which is mappable 492 to multiple schema representations. 494 7.4. Netconf 496 Given a YAML implementation of this information model it would be 497 possible to create a Netconf-based interface to the KDC in theory 498 enabling management of the KDC from standard network management 499 applications 501 8. Security Considerations 503 This document describes an abstract information model for Kerberos 5. 504 The Kerberos 5 protocol depends on the security of the keys stored in 505 the KDC. The model described here assumes that keys MUST NOT be 506 transported in the clear over the network and furthermore that keys 507 are treated as write-only attributes that SHALL only be modified 508 (using the administrative interface) by the change-password protocol 509 [I-D.ietf-krb-wg-kerberos-set-passwd]. 511 Exposing the object model of a KDC typically implies that objects can 512 be modified and/or deleted. In a KDC not all principals are created 513 equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM 514 effectively disables the EXAMPLE.COM realm. Hence access control is 515 paramount to the security of any implementation. This document does 516 not (at the time of writing - leifj) mandate access control. This 517 only implies that access control is beyond the scope of the standard 518 information model, i.e that access control may not be accessible via 519 any protocol based on this model. If access control objects is 520 exposed via an extension to this model the presence of access control 521 may in itself provide points of attack by giving away information 522 about principals with elevated rights etc. etc. 524 9. IANA Considerations 526 This document requires the allocation of several OIDs marked in 527 the text. 529 10. References 531 10.1. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, March 1997. 536 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 537 Kerberos 5", RFC 3961, February 2005. 539 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 540 Kerberos Network Authentication Service (V5)", RFC 4120, 541 July 2005. 543 10.2. Informative References 545 [I-D.ietf-krb-wg-kerberos-set-passwd] 546 Williams, N., "Kerberos Set/Change Key/Password Protocol 547 Version 2", draft-ietf-krb-wg-kerberos-set-passwd-08 (work 548 in progress), November 2008. 550 Author's Address 552 Leif Johansson 553 Swedish University Network 554 Thulegatan 11 555 Stockholm 557 Email: leifj@sunet.se 558 URI: http://www.sunet.se