idnits 2.17.1 draft-ietf-krb-wg-kdc-model-08.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 (May 18, 2010) is 5064 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 May 18, 2010 5 Expires: November 19, 2010 7 An information model for Kerberos version 5 8 draft-ietf-krb-wg-kdc-model-08 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 November 19, 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 administer 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. Neither an 108 object oriented model nor an LDAP schema is intended. The author has 109 attempted to describe in natural language the intended semantics and 110 syntax of the components of the model. An LDAP schema (for instance) 111 based on this model will be more precise in the expression of the 112 syntax while preserving the semantics of this model. 114 Implementations of this document MAY decide to change the names used 115 (e.g. principalName). If so an implementation MUST provide a name to 116 name mapping to this document. 118 3. How to interpret RFC2119 terms 120 This document describes an information model for kerberos 5 but does 121 not directly describe any mapping onto a particular schema- or 122 modelling language. Hence an implementation of this model consists 123 of a mapping to such a language - e.g. an LDAP or SQL schema. The 124 precise interpretation of terms from [RFC2119] therefore require some 125 extra explanation. The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL 126 NOT mean that an implementation MUST provide a feature but does not 127 mean that this feature MUST be REQUIRED by the implementation - e.g. 128 an attribute is available in an LDAP schema but marked as OPTIONAL. 129 If a feature must be implemented and REQUIRED this is made explicit 130 in this model. The term MAY, OPTIONAL and RECOMMENDED means that an 131 implementation MAY need to REQUIRE the feature due to the particular 132 nature of the schema/modelling language. In some cases this is 133 expressly forbidden by this model (feature X MUST NOT be REQUIRED by 134 an implementation). 136 Any implementation of this model SHOULD be published as an RFC. 138 4. Acknowledgments 140 Love Hoernquist-Aestrand for important contributions. 142 5. Information model demarcation 144 The information model specified in the next chapter describes 145 objects, properties of those objects and relations between those 146 objects. These elements comprise an abstract view of the data 147 represented in a KDC. It is important to understand that the 148 information model is not a schema. In particular the way objects are 149 compared for equality beyond that which is implied by the 150 specification of a syntax is not part of this specification. Nor is 151 ordering specified between elements of a particular syntax. 153 Further work on Kerberos will undoubtedly prompt updates to this 154 information model to reflect changes in the functions performed by 155 the KDC. Such extensions to the information model MUST always use a 156 normative reference to the relevant RFCs detailing the change in KDC 157 function. 159 This model describes a number of elements related to password policy 160 management. Not all of the elements in this model are unique to 161 Kerberos; an LDAP implementation of this model should incorporate 162 existing LDAP schema where functional overlap exists, rather than 163 defining additional Kerberos-specific elements. 165 6. Information model specification 167 6.1. Principal 169 The fundamental entity stored in a KDC is the principal. The 170 principal is associated to keys and generalizes the "user" concept. 171 The principal MUST be implemented in full and MUST NOT be optional in 172 an implementation 174 6.1.1. Principal: Attributes 176 6.1.1.1. principalName 178 The principalName MUST uniquely identify the principal within the 179 administrative context of the KDC. The principalName MUST be 180 equivalent to the string representation of the principal name 181 including, if applicable for the name type, the realm. 183 The attribute MAY be multi-valued if the implementation supports 184 aliases and/or enterprise names. In that case exactly one of the 185 principalName values MAY be designated the canonical principalName 186 and if the implementation supports enctypes which require salt then 187 exactly one of the values of principalName MAY be designated as the 188 canonical salting principalName. 190 Implementations (i.e. schema) that support enterprise names and/or 191 aliases SHOULD provide for efficient lookup of principal objects 192 based on alias/enterprise name. 194 6.1.1.2. principalNotUsedBefore 196 The principal may not be used before 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.3. principalNotUsedAfter 202 The principal may not be used after this date. The syntax of the 203 attribute MUST be semantically equivalent with the standard ISO date 204 format. The attribute MUST be single-valued. 206 6.1.1.4. principalIsDisabled 208 A boolean attribute used to disable a principal. The attribute 209 SHOULD default to false. 211 6.1.1.5. principalNumberOfFailedAuthenticationAttempts 213 This single-valued integer attribute contains a count of the number 214 of times an authentication attempt was unsuccessful for this 215 principal. Implementations SHOULD NOT allow this counter to be 216 reset. 218 6.1.1.6. principalLastFailedAuthentication 220 This single-valued attribute contains the time and date for the last 221 failed authentication attempt for this principal. 223 6.1.1.7. principalLastSuccessfulAuthentication 225 This single-valued attribute contains the time and date for the last 226 successful authentication attempt for this principal. 228 6.1.1.8. principalLastCredentialChangeTime 230 This single-valued attribute contains the time and date for the last 231 successful change of credential (e.g. password or private key) 232 associated with this principal. 234 6.1.1.9. principalCreateTime 236 This single-valued attribute contains the time and date when this 237 principal was created 239 6.1.1.10. principalModifyTime 241 This single-valued attribute contains the time and date when this 242 principal was modified excluding credentials change. 244 6.1.1.11. principalMaximumTicketLifetime 246 This single-valued attribute contains the delta time in seconds 247 representing the maximum lifetime for tickets issued for this 248 principal. 250 6.1.1.12. principalMaximumRenewableTicketLifetime 252 This single-valued attribute contains the delta time in seconds 253 representing the maximum amount of time a ticket may be renewed for. 255 6.1.1.13. principalAllowedEnctype 257 This OPTIONAL multi-valued attribute lists the enctypes allowed for 258 this principal. If empty or absent any enctype supported by the 259 implementation is allowed for this principal. 261 This attribute is intended as a policy attribute and restricts all 262 uses of enctypes including server, client, and session keys. Data 263 models MAY choose to use policy objects in order to represent more 264 complex decision mechanisms. 266 6.1.2. Principal: Associations 268 Each principal MAY be associated with 0 or more KeySet and MAY be 269 associated with 0 or more Policies. The KeySet is represented as an 270 object in this model since it has attributes associated with it (the 271 key version number). In typical situations the principal is 272 associated with exactly 1 KeySet but implementations MUST NOT assume 273 this case, i.e. an implementation of this standard MUST be able to 274 handle the general case of multiple KeySet associated with each 275 principal. Multiple KeySets may for instance be useful when 276 performing a key rollover for a principal. 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 a data- 282 model. It is expected that most Kerberos implementations will use 283 the set/change password protocol for all aspects of key management 284 [I-D.ietf-krb-wg-kerberos-set-passwd]. This information model only 285 includes these objects for the sake of completeness. 287 If a server supports an enctype for a principal that enctype must be 288 present in at least one key for the principal in question. 290 6.2.1. KeySet: Attributes 292 6.2.1.1. keySetVersionNumber 294 This is traditionally called the key version number (kvno). This is 295 a single-valued attribute containing a positive integer. 297 6.2.2. KeySet: Associations 299 To each KeySet MUST be associated a set of 1 or more Keys. 301 6.2.3. KeySet: Remarks 303 The security of Kerberos 5 depends absolutely on the confidentiality 304 and integrity of the keys stored in the KDC. Implementations of this 305 standard MUST facilitate, to the extent possible, an administrator's 306 ability to place more restrictive access controls on KeySets than on 307 other principal data, and to arrange for more secure backup for 308 KeySets. 310 6.3. Key 312 Implementations of this model MUST NOT REQUIRE keys to be 313 represented. 315 6.3.1. Key: Attributes 317 6.3.1.1. keyEncryptionType 319 The enctype SHOULD be represented as an enumeration of the enctypes 320 supported by the KDC using the string name of the enctype from 321 [RFC3961] 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. keyNotUsedBefore 340 This key MUST NOT be used before 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. keyNotUsedAfter 346 This key MUST NOT be used after 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. keyNotUsedBefore 352 This key MUST NOT be used before 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.8. keyIsDisabled 358 This is a boolean attribute which SHOULD be set to false by default. 359 If this attribute is true the key MUST NOT be used. This is used to 360 temporarily disable a key. 362 6.3.2. Key: Associations 364 None 366 6.3.3. Key: Remarks 368 The security of the keys is an absolute requirement for the operation 369 of Kerberos 5. If keys are implemented adequate protection from 370 unauthorized modification and disclosure MUST be available and 371 REQUIRED by the implementation. 373 6.4. Policy 375 Implementations SHOULD implement policy but MAY allow them to be 376 OPTIONAL. The Policy should be thought of as a 'typed hole'. i.e. an 377 opaque binary value paired with an identifier of type of data 378 contained in the binary value. Both attributes (type and value) must 379 be present. 381 6.4.1. Policy: Attributes 383 6.4.1.1. policyIdentifier 385 The policyIdentifier MUST be unique within the local administrative 386 context and MUST be globally unique. Possible types of identifiers 387 include: 389 An Object Identifier (OID) 391 A URI 393 A UUID 395 The use of OIDs is RECOMMENDED for this purpose. 397 6.4.1.2. policyIsCritical 399 This boolean attribute indicates that the KDC MUST be able to 400 correctly interpret and apply this policy for the key to be used. 402 6.4.1.3. policyContent 404 This is an optional single opaque binary value used to store a 405 representation of the policy. In general a policy cannot be fully 406 expressed using attribute-value pairs. The policyContent is OPTIONAL 407 in the sense that an implementation MAY use it to store an opaque 408 value for those policy-types which are not directly representable in 409 that implementation. 411 6.4.1.4. policyUse 413 This is an optional single enumerated string value used to describe 414 the use of the policy. Implementations SHOULD provide this attribute 415 and MUST (if the attribute is implemented) describe the enumerated 416 set of possible values. The intent is that this attribute be useful 417 in providing an initial context-based filtering. 419 6.4.2. Mandatory-to-implement Policy 421 All implementations MUST be able to represent the policies listed in 422 this section. Implementations are not required to use the same 423 underlying data-representation for the policyContent binary value but 424 SHOULD use the same OIDs as the policyIdentifier. In general the 425 expression of policy may require a Turing-complete language. This 426 specification does not attempt to model policy expression language. 428 6.4.2.1. Password Quality Policy 430 Password quality policy controls the requirements placed by the KDC 431 on new passwords. This policy SHOULD be identified by the OID 432 .1. 434 6.4.2.2. Password Management Policy 436 Password management policy controls how passwords are changed. This 437 policy SHOULD be identified by the OID .2. 439 6.4.2.3. Keying Policy 441 A keying policy specifies the association of enctypes with new 442 principals, e.g. when a principal is created one of the applicable 443 keying policies is used to determine the set of keys to associate 444 with the principal. This policy SHOULD be identified by the OID 445 .3. 447 6.4.2.4. Ticket Flag Policy 449 A ticket flag policy specifies the ticket flags allowed for tickets 450 issued for a principal. This policy SHOULD be identified by the OID 451 .4. 453 7. Implementation Scenarios 455 There are several ways to implement an administrative service for 456 Kerberos 5 based on this information model. In this section we list 457 a few of them. 459 7.1. LDAP backend to KDC 461 Given an LDAP schema implementation of this information model it 462 would be possible to build an administrative service by back-ending 463 the KDC to a directory server where principals and keys are stored. 464 Using the security mechanisms available on the directory server keys 465 are protected from access by anyone apart from the KDC. 466 Administration of the principals, policy, and other non-key data is 467 done through the directory server while the keys are modified using 468 the set/change password protocol 469 [I-D.ietf-krb-wg-kerberos-set-passwd]. 471 7.2. LDAP frontend to KDC 473 An alternative way to provide a directory interface to the KDC is to 474 implement an LDAP-frontend to the KDC which exposes all non-key 475 objects as entries and attributes. As in the example above all keys 476 are modified using the set/change password protocol 477 [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the 478 implementation would typically not use a traditional LDAP 479 implementation but treat LDAP as an access protocol to data in the 480 native KDC database. 482 7.3. SOAP 484 Given an XML schema implementation of this information model it would 485 be possible to build a SOAP interface to the KDC. This demonstrates 486 the value of creating an abstract information model which is mappable 487 to multiple schema representations. 489 7.4. Netconf 491 Given a YAML implementation of this information model it would be 492 possible to create a Netconf-based interface to the KDC, enabling 493 management of the KDC from standard network management applications. 495 8. Security Considerations 497 This document describes an abstract information model for Kerberos 5. 498 The Kerberos 5 protocol depends on the security of the keys stored in 499 the KDC. The model described here assumes that keys MUST NOT be 500 transported in the clear over the network and furthermore that keys 501 are treated as write-only attributes that SHALL only be modified 502 (using the administrative interface) by the change-password protocol 503 [I-D.ietf-krb-wg-kerberos-set-passwd]. 505 Exposing the object model of a KDC typically implies that objects can 506 be modified and/or deleted. In a KDC not all principals are created 507 equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM 508 effectively disables the EXAMPLE.COM realm. Hence access control is 509 paramount to the security of any implementation. This document does 510 not mandate access control. This only implies that access control is 511 beyond the scope of the standard information model, i.e. that access 512 control may not be accessible via any protocol based on this model. 513 If access control objects are exposed via an extension to this model 514 the presence of access control may in itself provide points of attack 515 by giving away information about principals with elevated rights etc. 517 9. IANA Considerations 519 This document requires the allocation of several OIDs marked in 520 the text. 522 10. References 524 10.1. Normative References 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 530 Kerberos 5", RFC 3961, February 2005. 532 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 533 Kerberos Network Authentication Service (V5)", RFC 4120, 534 July 2005. 536 10.2. Informative References 538 [I-D.ietf-krb-wg-kerberos-set-passwd] 539 Williams, N., "Kerberos Set/Change Key/Password Protocol 540 Version 2", draft-ietf-krb-wg-kerberos-set-passwd-08 (work 541 in progress), November 2008. 543 Author's Address 545 Leif Johansson 546 Swedish University Network 547 Thulegatan 11 548 Stockholm 550 Email: leifj@sunet.se 551 URI: http://www.sunet.se