idnits 2.17.1 draft-johansson-kerberos-model-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 520. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 12, 2007) is 5981 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-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Johansson 3 Internet-Draft Stockholm university 4 Intended status: Standards Track November 12, 2007 5 Expires: May 15, 2008 7 An information model for Kerberos version 5 8 draft-johansson-kerberos-model-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 15, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes an information model for Kerberos version 5 42 from the point of view of an administrative service. There is no 43 standard for administrating a kerberos 5 KDC. This document 44 describes the services exposed by an administrative interface to a 45 KDC. 47 Table of Contents 49 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. How to interpret RFC2119 terms . . . . . . . . . . . . . . . . 5 52 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 53 5. Information model demarcation . . . . . . . . . . . . . . . . 7 54 6. Information model specification . . . . . . . . . . . . . . . 8 55 6.1. Principal . . . . . . . . . . . . . . . . . . . . . . . . 8 56 6.1.1. Principal: Attributes . . . . . . . . . . . . . . . . 8 57 6.1.2. Principal: Associations . . . . . . . . . . . . . . . 9 58 6.1.3. Principal: Remarks . . . . . . . . . . . . . . . . . . 9 59 6.2. KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 6.2.1. KeySet: Attributes . . . . . . . . . . . . . . . . . . 9 61 6.2.2. KeySet: Associations . . . . . . . . . . . . . . . . . 9 62 6.2.3. KeySet: Remarks . . . . . . . . . . . . . . . . . . . 10 63 6.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 6.3.1. Key: Attributes . . . . . . . . . . . . . . . . . . . 10 65 6.3.2. Key: Associations . . . . . . . . . . . . . . . . . . 11 66 6.3.3. Key: Remarks . . . . . . . . . . . . . . . . . . . . . 11 67 6.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6.4.1. Policy: Attributes . . . . . . . . . . . . . . . . . . 11 69 6.4.2. Password Quality Policy . . . . . . . . . . . . . . . 12 70 6.4.3. Password Management Policy . . . . . . . . . . . . . . 12 71 6.4.4. Keying Policy . . . . . . . . . . . . . . . . . . . . 12 72 7. Implementation Scenarios . . . . . . . . . . . . . . . . . . . 13 73 7.1. LDAP backend to KDC . . . . . . . . . . . . . . . . . . . 13 74 7.2. LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 13 75 7.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 10. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 Intellectual Property and Copyright Statements . . . . . . . . . . 19 85 1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Introduction 93 The Kerberos version 5 authentication service described in [RFC4120] 94 describes how a Key Distribution Service (KDC) provides 95 authentication to clients. The standard does not stipulate how a KDC 96 is managed and several "kadmin" servers have evolved. This document 97 describes the services required to administrate a KDC and the 98 underlying information model assumed by a kadmin-type service. 100 The information model is written in terms of "attributes" and 101 "services" or "interfaces" but the use of these particular words MUST 102 NOT be taken to imply any particular modeling paradigm so that 103 neither an object oriented model or an LDAP schema is intended. The 104 author has attempted to describe in natural language the intended 105 semantics and syntax of the components of the model. An LDAP schema 106 (for instance) based on this model will be more precise in the 107 expression of the syntax while preserving the semantics of this 108 model. 110 Implementations of this document MAY decide to change the names used 111 (eg principalName). If so an implementation MUST provide a name to 112 name mapping to this document. 114 3. How to interpret RFC2119 terms 116 This document describes an information model for kerberos 5 but does 117 not directly describe any mapping onto a particular schema- or 118 modelling language. Hence an implementation of this model consists 119 of a mapping to such a language - eg an LDAP or SQL schema. The 120 precise interpretation of terms from [RFC2119] therefore require some 121 extra explanation. The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL 122 NOT mean that an implementation MUST provide a feature but does not 123 mean that this feature MUST be REQUIRED by the implementation - eg an 124 attribute is available in an LDAP schema but marked as OPTIONAL. If 125 a feature must be implemented and REQUIRED this is made explicit in 126 this model. The term MAY, OPTIONAL and RECOMMENDED means that an 127 implementation MAY need to REQUIRE the feature due to the particular 128 nature of the schema/modelling language. In some cases this is 129 expressly forbidden by this model (feature X MUST NOT be REQUIRED by 130 an implementation). 132 Note that any implementation of this model SHOULD be published as an 133 RFC. 135 4. Acknowledgments 137 Love Hoernquist-Aestrand for important contributions. 139 5. Information model demarcation 141 The information model specified in the next chapter describes 142 objects, properties of those objects and relations between those 143 objects. These elements comprise an abstract view of the data 144 represented in a KDC. It is important to understand that the 145 information model is not a schema. In particular the way objects are 146 compared for equality beyond that which is implied by the 147 specification of a syntax is not part of this specification. Nor is 148 ordering specified between elements of a particular syntax. 150 Further work on Kerberos will undoubtedly prompt updates to this 151 information model to reflect changes in the functions performed by 152 the KDC. Such extensions to the information model MUST always use a 153 normative reference to the relevant RFCs detailing the change in KDC 154 function. 156 6. Information model specification 158 6.1. Principal 160 The fundamental entity stored in a KDC is the principal. The 161 principal is associated to keys and generalizes the "user" concept. 162 The principal MUST be implemented in full and MUST NOT be optional in 163 an implementation 165 6.1.1. Principal: Attributes 167 6.1.1.1. principalName 169 The principalName MUST uniquely identify the principal within the 170 administrative context of the KDC. The type of the principalName is 171 not described in this document. It is a unique identifier and can be 172 viewed as an opaque byte string which can be compared for equality. 173 The attribute SHOULD be single valued. If an implementation supports 174 multiple values it MUST treat one of the values as special and allow 175 it to be fetched as if it was a single value. 177 6.1.1.2. principalNotUsedBefore 179 The principal may not be used before this date. The syntax of the 180 attribute MUST be semantically equivalent with the standard ISO date 181 format. The attribute MUST be single valued. 183 6.1.1.3. principalNotUsedAfter 185 The principal may not be used after 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.4. principalIsDisabled 191 A boolean attribute used to (temporarily) disable a principal. The 192 attribute MUST default to false. 194 6.1.1.5. principalAliases 196 This multivalued attribute contains an unordered set of aliases for 197 the principal. Each alias SHOULD be unique within the administrative 198 domain represented by the KDC. The syntax of an alias is an opaque 199 identifier which can be compared for equality. 201 6.1.2. Principal: Associations 203 Each principal MAY be associated with 1 or more KeySet and MAY be 204 associated with 1 or more Policies. The KeySet is represented as an 205 object in this model since it has attributes associated with it (the 206 key version number). In typical situations the principal is 207 associated with exactly 1 KeySet but implementations MUST NOT assume 208 this case, i.e an implemenation of this standard (e.g an LDAP schema) 209 MUST be able to handle the general case of multiple KeySet associated 210 with each principal. 212 6.1.3. Principal: Remarks 214 Traditionally a principal consists of a local-part and a realm 215 denoted in string form by local-part@REALM. The realm concept is 216 used to provide administrative boundaries and together with cross- 217 realm authentication provides scalability to Kerberos 5. However the 218 realm is not central to an administrative information model. For 219 instance the initialization or creation of a realm is equivalent to 220 creating a specific set of principals (krbtgt@REALM, etc) which is 221 covered by the model and services described in this document. A 222 realm is typically associated with policy covering (for instance) 223 keying and password management. The management of such policy and 224 their association to realms is beyond the scope of this document. 226 6.2. KeySet 228 A KeySet is a set of keys associated with exactly one principal. 229 This object and its associations MUST NOT be REQUIRED by an 230 implementation. It is expected that most implementations of this 231 standard will use the set/change password protocol for all aspects of 232 key management [I-D.ietf-krb-wg-kerberos-set-passwd]. This 233 information model only includes these objects for the sake of 234 completenes. 236 6.2.1. KeySet: Attributes 238 6.2.1.1. keySetVersionNumber 240 This is traditionally called the key version number (kvno). This is 241 a single valued attribute containing a positive integer. 243 6.2.2. KeySet: Associations 245 To each KeySet MUST be associated a set of 1 or more Keys. 247 6.2.3. KeySet: Remarks 249 The reason for separating the KeySet from the Principal is security. 250 The security of Kerberos 5 depends absolutely on the security of the 251 keys stored in the KDC. The KeySet type is provided to make this 252 clear and to make separation of keys from other parts of the model 253 clear. 255 Implementations of this standard (eg an LDAP schema) MUST make a 256 clear separation between the representation of KeySet from other 257 information objects. 259 6.3. Key 261 Implementations of this model MUST NOT REQUIRE keys to be 262 represented. 264 6.3.1. Key: Attributes 266 6.3.1.1. keyEncryptionType 268 The enctype SHOULD be represented as an enumeration of the enctypes 269 supported by the KDC. 271 6.3.1.2. keyValue 273 The binary representation of the key data. This MUST be a single 274 valued octet string. 276 6.3.1.3. keySaltValue 278 The binary representation of the key salt. This MUST be a single 279 valued octet string. 281 6.3.1.4. keyStringToKeyParameter 283 This MUST be a single valued octet string representing an opaque 284 parameter associated with the enctype. 286 6.3.1.5. keyNotUsedAfter 288 This key MUST NOT be used after this date. The syntax of the 289 attribute MUST be semantically equivalent with the standard ISO date 290 format. This MUST be a single-valued attribute. 292 6.3.1.6. keyNotUsedBefore 294 This key MUST NOT be used before this date. The syntax of the 295 attribute MUST be semantically equivalent with the standard ISO date 296 format. This MUST be a single-valued attribute. 298 6.3.1.7. keyIsDisabled 300 This is a boolean attribute which must be set to false by default. 301 If this attribute is true the key MUST NOT be used. This is used to 302 temporarily disable a key. 304 6.3.2. Key: Associations 306 None 308 6.3.3. Key: Remarks 310 The security of the keys is an absolute requirement for the operation 311 of Kerberos 5. If keys are implemented adequate protection from 312 unauthorized modification and disclosure MUST be available and 313 REQUIRED by the implementation. 315 6.4. Policy 317 Implementations SHOULD implement policy but MAY allow them to be 318 OPTIONAL. 320 6.4.1. Policy: Attributes 322 6.4.1.1. policyIdentifier 324 The policyIdentifier MUST be unique within the local administrative 325 context and MUST be globally unique. Possible types of identifiers 326 include: 328 An Object Identifier (OID) 330 A URN 332 A UUID 334 6.4.1.2. policyIsMandatory 336 This boolean attribute indicates that the KDC MUST be able to 337 correctly interpret and apply this policy for the key to be used. 339 6.4.1.3. policyContent 341 This is an optional opaque binary value used to store a 342 representation of the policy. In general a policy cannot be fully 343 expressed using attribute-value pairs. The policyContent is OPTIONAL 344 in the sense that an implementation MAY use it to store an opaque 345 value for those policy-types which are not directly representable in 346 that implementation. 348 6.4.2. Password Quality Policy 350 6.4.2.1. Password Quality Policy: Attributes 352 Password quality policy controls the requirements placed by the KDC 353 on new passwords. TODO: update with information from Nico 355 6.4.3. Password Management Policy 357 6.4.3.1. Password Management Policy: Attributes 359 Password management policy controls how passwords are changed. TODO: 360 update with information from Nico and Ludovic 362 6.4.4. Keying Policy 364 6.4.4.1. Keying Policy: Attributes 366 A keying policy specifies the association of enctypes with new 367 principals, i.e when a principal is created one of the possibly many 368 applicable keying policies determine the set of keys to associate 369 with the principal. In general the expression of a keying policy may 370 require a Turing-complete language. 372 7. Implementation Scenarios 374 There are several ways to implement an administrative service for 375 Kerberos 5 based on this information model. In this section we list 376 a few of them. 378 7.1. LDAP backend to KDC 380 Given an LDAP schema implementation of this information model it 381 would be possible to build an administrative service by backending 382 the KDC to a directory server where principals and keys are stored. 383 Using the security mechanisms available on the directory server keys 384 are protected from access by anyone apart from the KDC. 385 Administration of the principals, policy and other non-key data is 386 done through the directory server while the keys are modified using 387 the set/change password protocol 388 [I-D.ietf-krb-wg-kerberos-set-passwd]. 390 7.2. LDAP frontend to KDC 392 An alternative way to provide a directory interface to the KDC is to 393 implement an LDAP-frontend to the KDC which exposes all non-key 394 objects as entries and attributes. As in the example above all keys 395 are modified using the set/change password protocol 396 [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the 397 implementation would typically not use a traditional LDAP 398 implementation but treat LDAP as an access-protocol to data in the 399 native KDC database. 401 7.3. SOAP 403 Given an XML schema implementation of this information model it would 404 be possible to build a SOAP-interface to the KDC. This demonstrates 405 the value of creating an abstract information model which is mappable 406 to multiple schema representations. 408 8. Security Considerations 410 This document describes an abstract information model for Kerberos 5. 411 The Kerberos 5 protocol depends on the security of the keys stored in 412 the KDC. The model described here assumes that keys MUST NOT be 413 transported in the clear over the network and furthermore that keys 414 are treated as write-only attributes that SHALL only be modified 415 (using the administrative interface) by the change-password protocol 416 [I-D.ietf-krb-wg-kerberos-set-passwd]. 418 Exposing the object model of a KDC typically implies that objects can 419 be modified and/or deleted. In a KDC not all principals are created 420 equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM 421 effectively disables the EXAMPLE.COM realm. Hence access control is 422 paramount to the security of any implementation. This document does 423 not (at the time of writing - leifj) mandate access control. This 424 only implies that access control is beyond the scope of the standard 425 information model, i.e that access control may not be accessible via 426 any protocol based on this model. If access control objects is 427 exposed via an extension to this model the presence of access control 428 may in itself provide points of attack by giving away information 429 about principals with elevated rights etc. etc. 431 9. IANA Considerations 433 None 435 10. Remarks 437 A few notes and TODOs: 439 Do we want to model access control? I have received a few notes 440 on that from Love. It will affect both the model and the security 441 considerations but It may be relevant. The catch is that most 442 implementations (SOAP, LDAP, etc) will have acl mechanisms 443 separate from the data which makes modeling acls difficult. 444 Perhaps there are certain aspects of access control which can be 445 modeled with relative ease - for instance the ability to make an 446 object immutable. 448 Explanatory text on a few of the basic attributes that doesn't 449 just repeat the section title. 451 Expand on the password policy types. Is the subdivision into 452 quality and management policies valid? 454 11. References 456 11.1. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 462 Kerberos Network Authentication Service (V5)", RFC 4120, 463 July 2005. 465 11.2. Informative References 467 [I-D.ietf-krb-wg-kerberos-set-passwd] 468 Williams, N., "Kerberos Set/Change Key/Password Protocol 469 Version 2", draft-ietf-krb-wg-kerberos-set-passwd-06 (work 470 in progress), March 2007. 472 Author's Address 474 Leif Johansson 475 Stockholm university 476 Sektionen foer IT och Media 477 Stockholm SE-106 91 479 Email: leifj@it.su.se 480 URI: http://people.su.se/~leifj/ 482 Full Copyright Statement 484 Copyright (C) The IETF Trust (2007). 486 This document is subject to the rights, licenses and restrictions 487 contained in BCP 78, and except as set forth therein, the authors 488 retain all their rights. 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 493 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 494 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 495 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Intellectual Property 500 The IETF takes no position regarding the validity or scope of any 501 Intellectual Property Rights or other rights that might be claimed to 502 pertain to the implementation or use of the technology described in 503 this document or the extent to which any license under such rights 504 might or might not be available; nor does it represent that it has 505 made any independent effort to identify any such rights. Information 506 on the procedures with respect to rights in RFC documents can be 507 found in BCP 78 and BCP 79. 509 Copies of IPR disclosures made to the IETF Secretariat and any 510 assurances of licenses to be made available, or the result of an 511 attempt made to obtain a general license or permission for the use of 512 such proprietary rights by implementers or users of this 513 specification can be obtained from the IETF on-line IPR repository at 514 http://www.ietf.org/ipr. 516 The IETF invites any interested party to bring to its attention any 517 copyrights, patents or patent applications, or other proprietary 518 rights that may cover technology that may be required to implement 519 this standard. Please address the information to the IETF at 520 ietf-ipr@ietf.org. 522 Acknowledgment 524 Funding for the RFC Editor function is provided by the IETF 525 Administrative Support Activity (IASA).