From e3c097abeb02b4ee559e699595853d4c503c0c1e Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Mon, 13 Aug 2007 14:52:27 +0200 Subject: [PATCH] Add. --- .../draft-johansson-kerberos-model-03.txt | 1065 ++++++++++++++++++++ ...draft-sakane-krb-cross-problem-statement-03.txt | 731 ++++++++++++++ 2 files changed, 1796 insertions(+) create mode 100644 doc/specifications/draft-johansson-kerberos-model-03.txt create mode 100644 doc/specifications/draft-sakane-krb-cross-problem-statement-03.txt diff --git a/doc/specifications/draft-johansson-kerberos-model-03.txt b/doc/specifications/draft-johansson-kerberos-model-03.txt new file mode 100644 index 00000000..35818e6e --- /dev/null +++ b/doc/specifications/draft-johansson-kerberos-model-03.txt @@ -0,0 +1,1065 @@ + + + +Network Working Group Johansson +Internet-Draft Stockholm university +Intended status: Standards Track July 8, 2007 +Expires: January 9, 2008 + + + An information model for Kerberos version 5 + draft-johansson-kerberos-model-03 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 9, 2008. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 1] + +Internet-Draft KDC Information Model July 2007 + + +Abstract + + This document describes an information model for Kerberos version 5 + from the point of view of an administrative service. There is no + standard for administrating a kerberos 5 KDC. This document + describes the services exposed by an administrative interface to a + KDC. + + +Table of Contents + + 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. How to interpret RFC2119 terms . . . . . . . . . . . . . . . . 5 + 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Information model demarcation . . . . . . . . . . . . . . . . 7 + 6. Information model specification . . . . . . . . . . . . . . . 8 + 6.1. Principal . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1.1. Principal: Attributes . . . . . . . . . . . . . . . . 8 + 6.1.2. Principal: Associations . . . . . . . . . . . . . . . 8 + 6.1.3. Principal: Remarks . . . . . . . . . . . . . . . . . . 9 + 6.2. KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 6.2.1. KeySet: Attributes . . . . . . . . . . . . . . . . . . 9 + 6.2.2. KeySet: Associations . . . . . . . . . . . . . . . . . 9 + 6.2.3. KeySet: Remarks . . . . . . . . . . . . . . . . . . . 9 + 6.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.3.1. Key: Attributes . . . . . . . . . . . . . . . . . . . 10 + 6.3.2. Key: Associations . . . . . . . . . . . . . . . . . . 10 + 6.3.3. Key: Remarks . . . . . . . . . . . . . . . . . . . . . 11 + 6.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.4.1. Policy: Attributes . . . . . . . . . . . . . . . . . . 11 + 6.4.2. Password Quality Policy . . . . . . . . . . . . . . . 11 + 6.4.3. Password Management Policy . . . . . . . . . . . . . . 12 + 6.4.4. Keying Policy . . . . . . . . . . . . . . . . . . . . 12 + 7. Implementation Scenarios . . . . . . . . . . . . . . . . . . . 13 + 7.1. LDAP backend to KDC . . . . . . . . . . . . . . . . . . . 13 + 7.2. LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 13 + 7.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 10. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . . . . . 19 + + + + + +Johansson Expires January 9, 2008 [Page 2] + +Internet-Draft KDC Information Model July 2007 + + +1. Requirements notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 3] + +Internet-Draft KDC Information Model July 2007 + + +2. Introduction + + The Kerberos version 5 authentication service described in [RFC4120] + describes how a Key Distribution Service (KDC) provides + authentication to clients. The standard does not stipulate how a KDC + is managed and several "kadmin" servers have evolved. This document + describes the services required to administrate a KDC and the + underlying information model assumed by a kadmin-type service. + + The information model is written in terms of "attributes" and + "services" or "interfaces" but the use of these particular words MUST + NOT be taken to imply any particular modeling paradigm so that + neither an object oriented model or an LDAP schema is intended. The + author has attempted to describe in natural language the intended + semantics and syntax of the components of the model. An LDAP schema + (for instance) based on this model will be more precise in the + expression of the syntax while preserving the semantics of this + model. + + Implementations of this document MAY decide to change the names used + (eg principalName). If so an implementation MUST provide a name to + name mapping to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 4] + +Internet-Draft KDC Information Model July 2007 + + +3. How to interpret RFC2119 terms + + This document describes an information model for kerberos 5 but does + not directly describe any mapping onto a particular schema- or + modelling language. Hence an implementation of this model consists + of a mapping to such a language - eg an LDAP or SQL schema. The + precise interpretation of terms from [RFC2119] therefore require some + extra explanation. The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL + NOT mean that an implementation MUST provide a feature but does not + mean that this feature MUST be REQUIRED by the implementation - eg an + attribute is available in an LDAP schema but marked as OPTIONAL. If + a feature must be implemented and REQUIRED this is made explicit in + this model. The term MAY, OPTIONAL and RECOMMENDED means that an + implementation MAY need to REQUIRE the feature due to the particular + nature of the schema/modelling language. In some cases this is + expressly forbidden by this model (feature X MUST NOT be REQUIRED by + an implementation). + + Note that any implementation of this model SHOULD be published as an + RFC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 5] + +Internet-Draft KDC Information Model July 2007 + + +4. Acknowledgments + + Love Hoernquist-Aestrand for important contributions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 6] + +Internet-Draft KDC Information Model July 2007 + + +5. Information model demarcation + + The information model specified in the next chapter describes + objects, properties of those objects and relations between those + objects. These elements comprise an abstract view of the data + represented in a KDC. It is important to understand that the + information model is not a schema. In particular the way objects are + compared for equality beyond that which is implied by the + specification of a syntax is not part of this specification. Nor is + ordering specified between elements of a particular syntax. + + Further work on Kerberos will undoubtedly prompt updates to this + information model to reflect changes in the functions performed by + the KDC. Such extensions to the information model MUST always use a + normative reference to the relevant RFCs detailing the change in KDC + function. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 7] + +Internet-Draft KDC Information Model July 2007 + + +6. Information model specification + +6.1. Principal + + The fundamental entity stored in a KDC is the principal. The + principal is associated to keys and generalizes the "user" concept. + The principal MUST be implemented in full and MUST NOT be optional in + an implementation + +6.1.1. Principal: Attributes + +6.1.1.1. principalName + + The principalName MUST uniquely identify the principal within the + administrative context of the KDC. The type of the principalName is + not described in this document. It is a unique identifier and can be + viewed as an opaque which can be compared for equality. + +6.1.1.2. principalNotUsedBefore + + The principal may not be used before this date. The syntax of the + attribute MUST be semantically equivalent with the standard ISO date + format. + +6.1.1.3. principalNotUsedAfter + + The principal may not be used after this date. The syntax of the + attribute MUST be semantically equivalent with the standard ISO date + format. + +6.1.1.4. principalIsDisabled + + A boolean attribute used to temporarily disable a principal. + +6.1.1.5. principalAliases + + This multivalued attribute contains a set of aliases for the + principal. + +6.1.2. Principal: Associations + + Each principal MAY be associated with 1 or more KeySet and MAY be + associated with 1 or more Policies. The KeySet is represented as an + object in this model since it has attributes associated with it (the + key version number). In typical situations the principal is + associated with exactly 1 KeySet but implementations MUST NOT assume + this case, i.e an implemenation of this standard (e.g an LDAP schema) + MUST be able to handle the general case of multiple KeySet associated + + + +Johansson Expires January 9, 2008 [Page 8] + +Internet-Draft KDC Information Model July 2007 + + + with each principal. + +6.1.3. Principal: Remarks + + Traditionally a principal consists of a local-part and a realm + denoted in string form by local-part@REALM. The realm concept is + used to provide administrative boundaries and together with cross- + realm authentication provides scalability to Kerberos 5. However the + realm is not central to an administrative information model. For + instance the initialization or creation of a realm is equivalent to + creating a specific set of principals (krbtgt@REALM, etc) which is + covered by the model and services described in this document. A + realm is typically associated with policy covering (for instance) + keying and password management. The management of such policy and + their association to realms is beyond the scope of this document. + +6.2. KeySet + + A KeySet is a set of keys associated with exactly one principal. + This object and its associations MUST NOT be REQUIRED by an + implementation. It is expected that most implementations of this + standard will use the set/change password protocol for all aspects of + key management [I-D.ietf-krb-wg-kerberos-set-passwd]. This + information model only includes these objects for the sake of + completenes. + +6.2.1. KeySet: Attributes + +6.2.1.1. keySetVersionNumber + + This is traditionally called the key version number (kvno). + +6.2.2. KeySet: Associations + + To each KeySet MUST be associated a set of 1 or more Keys. + +6.2.3. KeySet: Remarks + + The reason for separating the KeySet from the Principal is security. + The security of Kerberos 5 depends absolutely on the security of the + keys stored in the KDC. The KeySet type is provided to make this + clear and to make separation of keys from other parts of the model + clear. + + Implementations of this standard (eg an LDAP schema) MUST preserve + this distinction. + + + + + +Johansson Expires January 9, 2008 [Page 9] + +Internet-Draft KDC Information Model July 2007 + + +6.3. Key + + Implementations of this model MUST NOT REQUIRE keys to be + represented. + +6.3.1. Key: Attributes + +6.3.1.1. keyEncryptionType + + The enctype. The precise representation depends on the + implementation. + +6.3.1.2. keyValue + + The binary representation of the key data. + +6.3.1.3. keySaltValue + + The binary representation of the key salt. + +6.3.1.4. keyStringToKeyParameter + + The syntax of this opaque object is defined by the encryption type + used. + +6.3.1.5. keyNotUsedAfter + + This key MUST NOT be used after this date. The syntax of the + attribute MUST be semantically equivalent with the standard ISO date + format. + +6.3.1.6. keyNotUsedBefore + + This key MUST NOT be used before this date. The syntax of the + attribute MUST be semantically equivalent with the standard ISO date + format. + +6.3.1.7. keyIsDisabled + + If this attribute is true the key MUST NOT be used. This is used to + temporarily disable a key. + +6.3.2. Key: Associations + + None + + + + + + +Johansson Expires January 9, 2008 [Page 10] + +Internet-Draft KDC Information Model July 2007 + + +6.3.3. Key: Remarks + + The security of the keys is an absolute requirement for the operation + of Kerberos 5. If keys are implemented adequate protection from + unauthorized modification and disclosure MUST be available and + REQUIRED by the implementation. + +6.4. Policy + + Implementations SHOULD implement policy but MAY allow them to be + OPTIONAL. + +6.4.1. Policy: Attributes + +6.4.1.1. policyIdentifier + + The policyIdentifier MUST be unique within the local administrative + context and MUST be globally unique. Possible types of identifiers + include: + + An Object Identifier (OID) + + A URN + + A UUID + +6.4.1.2. policyIsMandatory + + This attribute indicates that the KDC MUST be able to correctly + interpret and apply this policy for the key to be used. + +6.4.1.3. policyContent + + This is an optional opaque binary value used to store a + representation of the policy. In general a policy cannot be fully + expressed using attribute-value pairs. The policyContent is OPTIONAL + in the sense that an implementation MAY use it to store an opaque + value for those policy-types which are not directly representable in + that implementation. + +6.4.2. Password Quality Policy + +6.4.2.1. Password Quality Policy: Attributes + + Password quality policy controls the requirements placed by the KDC + on new passwords. TODO: update with information from Nico + + + + + +Johansson Expires January 9, 2008 [Page 11] + +Internet-Draft KDC Information Model July 2007 + + +6.4.3. Password Management Policy + +6.4.3.1. Password Management Policy: Attributes + + Password management policy controls how passwords are changed. TODO: + update with information from Nico and Ludovic + +6.4.4. Keying Policy + +6.4.4.1. Keying Policy: Attributes + + A keying policy specifies the association of enctypes with new + principals, i.e when a principal is created one of the possibly many + applicable keying policies determine the set of keys to associate + with the principal. In general the expression of a keying policy may + require a Turing-complete language. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 12] + +Internet-Draft KDC Information Model July 2007 + + +7. Implementation Scenarios + + There are several ways to implement an administrative service for + Kerberos 5 based on this information model. In this section we list + a few of them. + +7.1. LDAP backend to KDC + + Given an LDAP schema implementation of this information model it + would be possible to build an administrative service by backending + the KDC to a directory server where principals and keys are stored. + Using the security mechanisms available on the directory server keys + are protected from access by anyone apart from the KDC. + Administration of the principals, policy and other non-key data is + done through the directory server while the keys are modified using + the set/change password protocol + [I-D.ietf-krb-wg-kerberos-set-passwd]. + +7.2. LDAP frontend to KDC + + An alternative way to provide a directory interface to the KDC is to + implement an LDAP-frontend to the KDC which exposes all non-key + objects as entries and attributes. As in the example above all keys + are modified using the set/change password protocol + [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the + implementation would typically not use a traditional LDAP + implementation but treat LDAP as an access-protocol to data in the + native KDC database. + +7.3. SOAP + + Given an XML schema implementation of this information model it would + be possible to build a SOAP-interface to the KDC. This demonstrates + the value of creating an abstract information model which is mappable + to multiple schema representations. + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 13] + +Internet-Draft KDC Information Model July 2007 + + +8. Security Considerations + + This document describes an abstract information model for Kerberos 5. + The Kerberos 5 protocol depends on the security of the keys stored in + the KDC. The model described here assumes that keys MUST NOT be + transported in the clear over the network and furthermore that keys + are treated as write-only attributes that SHALL only be modified + (using the administrative interface) by the change-password protocol + [I-D.ietf-krb-wg-kerberos-set-passwd]. + + Exposing the object model of a KDC typically implies that objects can + be modified and/or deleted. In a KDC not all principals are created + equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM + effectively disables the EXAMPLE.COM realm. Hence access control is + paramount to the security of any implementation. This document does + not (at the time of writing - leifj) mandate access control. This + only implies that access control is beyond the scope of the standard + information model, i.e that access control MAY NOT be accessible via + any protocol based on this model. If access control objects is + exposed via an extension to this model the presence of access control + may in itself provide points of attack by giving away information + about principals with elevated rights etc. etc. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 14] + +Internet-Draft KDC Information Model July 2007 + + +9. IANA Considerations + + None + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 15] + +Internet-Draft KDC Information Model July 2007 + + +10. Remarks + + A few notes and TODOs: + + Do we want to model access control? I have received a few notes + on that from Love. It will affect both the model and the security + considerations but It may be relevant. The catch is that most + implementations (SOAP, LDAP, etc) will have acl mechanisms + separate from the data which makes modeling acls difficult. + Perhaps there are certain aspects of access control which can be + modeled with relative ease - for instance the ability to make an + object immutable. + + Explanatory text on a few of the basic attributes that doesn't + just repeat the section title. + + Expand on the password policy types. Is the subdivision into + quality and management policies valid? + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 16] + +Internet-Draft KDC Information Model July 2007 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + +11.2. Informative References + + [I-D.ietf-krb-wg-kerberos-set-passwd] + Williams, N., "Kerberos Set/Change Key/Password Protocol + Version 2", draft-ietf-krb-wg-kerberos-set-passwd-06 (work + in progress), March 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 17] + +Internet-Draft KDC Information Model July 2007 + + +Author's Address + + Leif Johansson + Stockholm university + Sektionen foer IT och Media + Stockholm SE-106 91 + + Email: leifj@it.su.se + URI: http://people.su.se/~leifj/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson Expires January 9, 2008 [Page 18] + +Internet-Draft KDC Information Model July 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Johansson Expires January 9, 2008 [Page 19] + + diff --git a/doc/specifications/draft-sakane-krb-cross-problem-statement-03.txt b/doc/specifications/draft-sakane-krb-cross-problem-statement-03.txt new file mode 100644 index 00000000..2ac425ad --- /dev/null +++ b/doc/specifications/draft-sakane-krb-cross-problem-statement-03.txt @@ -0,0 +1,731 @@ + + + + + + +INTERNET-DRAFT S. Sakane +Intended Status: Informational Yokogawa Electric Corp. +Expires: January 10, 2008 S. Zrelli + JAIST + M. Ishiyama + Toshiba Corp. + July 9, 2007 + + + Problem statement on the cross-realm operation + of Kerberos in a specific system + draft-sakane-krb-cross-problem-statement-03.txt + + + + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + This Internet-Draft expires in January 10, 2008. + + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + + + + + + +S.Sakane, et al. [Page 1] + +Internet-Draft July 2007 + + +Abstract + + There are some issues when the cross-realm operation of the Kerberos + Version 5 [RFC4120] is employed into actual specific systems. This + document describes some examples of actual systems, and lists + requirements and restriction of the operation in such system. Then + it describes issues when we apply the cross-realm operation to such + system. + + + +Conventions used in this document + + It is assumed that the readers are familiar with the terms and + concepts described in the Kerberos Version 5 [RFC4120]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +S.Sakane, et al. [Page 2] + +Internet-Draft July 2007 + + +Table of Contents + + 1. Introduction ................................................. 4 + 2. Kerberos system .............................................. 4 + 2.1. Kerberos basic operation ................................ 4 + 2.2. Cross-realm operation ................................... 5 + 3. Example of actual environment ................................ 6 + 4. Requirements ................................................. 7 + 5. Issues ....................................................... 8 + 5.1. Unreliability of authentication chain ................... 8 + 5.2. No PFS in case of the indirect trust model .............. 8 + 5.3. Scalability of the direct trust model ................... 9 + 5.4. Exposure to DoS Attacks ................................. 9 + 5.5. Client's performance .................................... 9 + 5.6. Pre-authentication problem in roaming scenarios ......... 10 + 6. Implementation consideration ................................. 10 + 7. IANA Considerations .......................................... 11 + 8. Security Considerations ...................................... 11 + 9. Acknowledgments .............................................. 11 + 10. References ................................................... 11 + 10.1. Normative References ................................... 11 + 10.2. Informative References ................................. 11 + Authors' Addresses ............................................... 12 + Full Copyright Statement ......................................... 12 + Intellectual Property Statement .................................. 13 + + + + + + + + + + + + + + + + + + + + + + + + + + +S.Sakane, et al. [Page 3] + +Internet-Draft July 2007 + + +1. Introduction + + The Kerberos Version 5 is a widely deployed mechanism that a server + can authenticate a client access. Each client belongs to a managed + domain called realm. Kerberos supports the authentication in case of + situation that a client and a server belong to different realms. + This is called the cross-realm operation. + + Meanwhile, there are lots of manners of operation in actual systems, + where Kerberos could be applied. Large system or distributed system + are typically split into several managed domain. The reason is, for + example, geographical reason or different management policy. Even in + such system, an authentication mechanism over the different managed + domains is required. When the cross-realm operation of Kerberos is + applied to such systems, some issues come out. + + This document briefly describes the Kerberos Version 5 system and the + cross-realm operation. Then, it describes two actual systems that + could be applied the Kerberos system, and describes seven + requirements of those systems in term both of management and + operation. Finally, it lists six issues of the cross-realm operation + when it is applied to those system. + + Note that this document might not describe whole of issues of the + cross-realm operation. It also does not propose any solution to + solve issues which described in this document. In further step, we + have to analyze the issues, define problems and explore the + solutions. This work will be in another document. + + This document is assumed that the readers are familiar with the terms + and concepts described in the Kerberos Version 5 [RFC4120]. + + +2. Kerberos system + + +2.1. Kerberos basic operation + + Kerberos [RFC4120] is a widely deployed authentication system. The + authentication process in Kerberos involves principals and a Key + Distribution Center (KDC). The principals can be users or services. + Each KDC maintains a principals database and shares a secret key with + each registered principal. + + The authentication process allows a user to acquire the needed + credentials from the KDC. These credentials allow services to + authenticate the users before granting them access to the resources. + An important part of the credentials are called Tickets. There are + + + +S.Sakane, et al. [Page 4] + +Internet-Draft July 2007 + + + two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket. + The TGT is obtained periodically from the KDC and has a limited limit + after which it expires and the user must renew it. The TGT is used + to obtain the other kind of tickets, Service Tickets. The user + obtains a TGT from the Authentication Service (AS), a logical + component of the KDC. The process of obtaining a TGT is referred to + as 'AS exchange'. When a TGT request is issued by an user, the AS + responds by sending a reply packet containing the credentials which + consists of the TGT along with a random key called 'TGS Session Key'. + The TGT contains a set of information encrypted using a secret key + associated with a special service referred to as TGS (Ticket Granting + Service). The TGS session key is encrypted using the user's key so + that the user can obtain the TGS session key only if she knows the + secret key shared with the KDC. The TGT then is used to obtain + Service Tickets from the Ticket Granting Service (TGS)- the second + component of the KDC. The process of obtaining service tickets is + referred to as 'TGS exchange'. The request for a service ticket + consists on a packet containing a TGT and an 'Authenticator'. The + Authenticator is encrypted using the TGS session key and contains the + identity of the user as well as time stamps (for protection against + replay attacks). After decrypting the TGT (which was encrypted by + the AS using the TGS's secret key), the TGS extracts the TGS session + key. Using that session key, it decrypts the Authenticator and + authenticates the user. Then, the TGS issues credentials requested + by the user. These credentials consist on a service ticket and a + session key that will be used to authenticate the user with the + desired application service. + + +2.2. Cross-realm operation + + The Kerberos protocol provides the cross-realm authentication + capabilities. This allows users to obtain service tickets to access + services in foreign realms. In order to access such services, the + users first contact their home KDC asking for a TGT that will be used + with the TGS of the foreign realm. If the home realm and the foreign + realm share keys and have an established trust relationship, the home + KDC delivers the requested TGT. + + However, if the home realm does not share inter-realm keys with the + foreign realm, the home KDC will provide a TGT that can be used with + an intermediary foreign realm that is likely to be sharing inter- + realm keys with the target realm. The client can use this + 'intermediary TGT' to communicate with the intermediary KDC which + will iterate the actions taken by the home KDC. If the intermediary + KDC does not share inter-realm keys with the target foreign realm it + will point the user to another intermediary KDC (just as in the first + exchange between the user and its home KDC). However, in the other + + + +S.Sakane, et al. [Page 5] + +Internet-Draft July 2007 + + + case (when it shares inter-realm keys with the target realm), the + intermediary KDC will issue a TGT that can be used with the KDC of + the target realm. After obtaining a TGT for the desired foreign + realm, the client uses it to obtain service tickets from the TGS of + the foreign realm. Finally, the user access the service using the + service ticket. + + When the realms belong to the same institution, a chain of trust can + be determined by the client or the KDC by following the DNS domain + hierarchy and supposing that the parent domains share keys with all + its child sub-domains. However, because the inter-realm trust model + is not necessarily constructing the hierarchic approach anytime, the + trust path must be specified manually. When intermediary realms are + involved, the success of the cross-realm operation completely depends + on the realms that are part of the authentication path. + + +3. Example of actual environment + + In order to help understanding both requirements and restriction, + this section describes scale and operation of actual systems, where + it is possible to apply Kerberos. + + We refer to actual petrochemical enterprise [SHELLCHEM], and show two + examples among its plants. The enterprise produces bulk + petrochemicals and their delivery to large industrial customers. + There are 43 typical plants of the enterprise all over the world. + They are managed by the operation sites placed in 35 countries. This + section shows two examples of them. + + One is an example of a centralized system [CSPC]. CSPC is operated + by a joint enterprise of two companies. This system is one of the + largest systems of this enterprise in the world. This is placed in + the area of 3.4 square kilo meters in the north coast of Daya Bay, + Guangdong, which is at the southeast of China. 3,000 network + segments are established in the system. 16,000 control devices are + connected to the local area network. These devices belong to + different 9 sub systems, A control device has some control points, + which are controlled and monitored by other devices remotely. There + are 200,000 control points in all. They are controlled by 3 + different control center. + + Another example is a distributed system [NAM]. The NAM (Nederlandse + Aardolie Maatschappij) is operated by a partnership company of two + enterprises that represent the oil company. This system is + constituted by some plants that are geographically distributed within + the range of 863 square kilometers in the northern part of + Netherlands. 26 plants, each is named "cluster", are scattered in + + + +S.Sakane, et al. [Page 6] + +Internet-Draft July 2007 + + + the area. They are connected each other by a private ATM WAN. Each + cluster has approximately 500-1,000 control devices. These devices + are managed by each local control center in each cluster. In the + entire system of the NAM, there are one million control points. + + In the both of the systems, the end devices are basically connected + to a local network by a twisted pair cable, which is a low band-width + of 32 kbps. Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS- + M16C], are employed by many control devices. Furthermore, to + suppress power consumption, these CPU may be lowered the number of + clocks. Because there is a requirement of the explosion-proof. The + requirement restricts the amount of total energy in the device. + + A device on the network collects data from other devices which are + monitoring condition of the system. The device uses the data to make + a decision how to control another devices. And then the device gives + more than one instruction that controls other devices. If it took + time for data to reach, they could not be associated. The travel + time of data from the device to the other device is demanded within 1 + second at least. + + A part of the operation, like control of these system, maintenance, + and the environmental monitoring, is consigned to an external + organization. Agents who are consigned walk around the plant to get + their information, or watch the plant from a remote site. + + +4. Requirements + + This section lists the requirements derived from the previous + section. R-1, R-2, R-3 and R-4 are related to the management of the + divided system. R-5, R-6 and R-7 are related to the restriction to + such industrial network. + + + R-1 It is necessary to partition a management domain into some + domains. Or it is necessary to delegate a management authority + to another independent management domain. + + R-2 It is necessary to allow different independent management + domains to coexist on the same network because two or more + organizations need to enter into the system and to management + it. + + R-3 It is necessary that a device controls other devices that belong + to a different domain. + + + + + +S.Sakane, et al. [Page 7] + +Internet-Draft July 2007 + + + R-4 It is necessary to consider that a device is not always + geographically or network topologically close to the other + devices even when the devices belong to a same management + domain. + + R-5 It is demanded to reduce the management cost as much as + possible. + + R-6 It is necessary to consider the processing performance of the + device. And, it is necessary to suppress the power consumption + of the device. + + R-7 It is necessary to consider bandwidth of the communication. + + +5. Issues + + This section lists the issues in the cross-realm operation when we + apply the Kerberos version 5 into the system described in the section + 3, and consider the system applied the Kerberos with the requirements + described in the section 4. + + +5.1. Unreliability of authentication chain + + When the relationship of trust is constructed like a chain or + hierarchical, the authentication path is not dependable since it + strongly depends on intermediary realms that might not be under the + same authority. If any of the realms in the authentication path is + not available, then the principals of the end-realms can not perform + the cross-realm operation. + + The end-point realms do not have full control and responsibility of + the success of the operations even if their respective KDCs are fully + functional. Dependability of a system decreases if the system relies + on uncontrolled components. We can not be sure at 100% about the + result of the authentication since we do not know how is it going in + intermediary realms. + + This issue will happen as a by-product of a result meeting the + requirements R-1 and R-2. + + +5.2. No PFS in case of the indirect trust model + + In [SPECCROSS], any KDC in the authentication path can learn the + session key that will be used between the client and the desired + service. This means that any intermediary realm is able to spoof the + + + +S.Sakane, et al. [Page 8] + +Internet-Draft July 2007 + + + identity either of the service or the client as well as to eavesdrop + on the communication between the client and the server. + + This issue will happen as a by-product of a result meeting the + requirements R-1 and R-2. + + +5.3. Scalability of the direct trust model + + In the direct relationship of trust between each realm, the realms + involved in the cross-realm operation share keys and their respective + TGS principals are registered in each other's KDC. When direct trust + relationships are used, the KDC of each realm must maintain keys with + all foreign realms. This can become a cumbersome task when the + number of realms increase. This also increases maintenance cost. + + This issue will happen as a by-product of a result meeting the + requirements R-1, R-2 and R-5. + + +5.4. Exposure to DoS Attacks + + One of the assumption made when allowing the cross-realm operation in + Kerberos is that users can communicate with KDCs located in remote + realms. This practice introduces security threats because KDCs are + open to the public network. Administrators may think of restricting + the access to the KDC to the trusted realms only. However, this + approach is not scalable and does not really protect the KDC. + Indeed, when the remote realms have several IP prefixes (e.g. control + centers or outsourcing companies, located world wide), then the + administrator of the local KDC must collect the list of prefixes that + belong to these organization. The filtering rules must then + explicitly allow the incoming traffic from any host that belongs to + one of these prefixes. This makes the administrator's tasks more + complicated and prone to human errors. And also, the maintenance + cost increases. On the other hand, when ranges of external IP + addresses are allowed to communicate with the KDC, the risk of + becoming target to attacks from remote malicious users increases. + + +5.5. Client's performance + + In the cross-realm operation, Kerberos clients have to perform TGS + exchanges with all the KDCs in the trust path, including the home KDC + and the target KDC. TGS exchange requires cryptographic operations. + This exchange demands important processing time especially when the + client has limited computational capabilities. The overhead of these + cross-realm exchanges grows into unacceptable delays. + + + +S.Sakane, et al. [Page 9] + +Internet-Draft July 2007 + + + We ported the MIT Kerberos library (version 1.2.4), implemented a + Kerberos client on our original board with H8 (16-bit, 20MHz), and + measured the process time of each Kerberos message [KRBIMPL]. It + takes 195 milliseconds to perform a TGS exchange with the on-board + H/W crypto engine. Indeed, this result seems reasonable to the + requirement of the response time for the control network. However, + we did not modify the clock speed of the H8 during our measurement. + The processing time must be slower in a actual environment because H8 + is used with lowered clock speed in such system. Also, the delays + can grow to unacceptable delays when the number of intermediary + realms increases. + + This issue will happen as a by-product of a result meeting the + requirements R-1, R-2, R-6 and R-7. + + +5.6. Pre-authentication problem in roaming scenarios + + In roaming scenarios, the client needs to contact her home KDC to + obtain a cross-realm TGT for the local (or visited) realm. However, + the policy of the network access providers or the gateway in the + local network usually does not allow clients to communicate with + hosts in the Internet unless they provide valid authentication + credentials. In this manner, the client encounters a chicken-and-egg + problem where two resources are interdependent; the Internet + connection is needed to contact the home KDC and for obtaining + credentials, and on the other hand, the Internet connection is only + granted for clients who have valid credentials. As a result, the + Kerberos protocol can not be used as it is for authenticating roaming + clients requesting network access. + + This issue will happen as a result meeting the requirements R-3 and + R-4. + + +6. Implementation consideration + + This document just describes issues of the cross-realm operation. + However, there are important matters to be considered, when we solve + these issues and implement solution. Solution must not introduce new + problem. Solution should use existing components or protocols as + much as possible, should not introduce any definition of new + component. Solution must not require a KDC to have any additional + process. You must not forget that there would be a trade-off matter + anytime. So an implementation may not solve all of the problems + stated in this document. + + + + + +S.Sakane, et al. [Page 10] + +Internet-Draft July 2007 + + +7. IANA Considerations + + This document makes no request of IANA. + + +8. Security Considerations + + This document just clarifies some issues of the cross-realm operation + of the Kerberos V system. There is especially not describing + security. Some troubles might be caused to your system by malicious + user who misuses the description of this document if it dares to say. + + +9. Acknowledgments + + The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa, + Ken'ichi Kamada and Atsushi Inoue. They gave us lots of comments and + input for this document. + + +10. References + + +10.1. Normative References + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC + 4120, July 2005. + + +10.2. Informative References + + [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id= + 531,00.html + + [KRBIMPL] "A Prototype of a Secure Autonomous Bootstrap Mechanism + for Control Networks", Nobuo Okabe, Shoichi Sakane, + Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki, + SAINT, pp. 56-62, IEEE Computer Society, 2006. + + [NAM] http://www.nam.nl/ + + [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing. + jsp&fp=/products/mpumcu/h8_family/ + + [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi + ng.jsp&fp=/products/mpumcu/m16c_family/ + + + + +S.Sakane, et al. [Page 11] + +Internet-Draft July 2007 + + + [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html + + [SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C. + Walstad, "Specifying Kerberos 5 Cross-Realm + Authentication", Fifth Workshop on Issues in the Theory + of Security, Jan 2005. + +Authors' Addresses + + Shoichi Sakane + Yokogawa Electric Corporation + 2-9-32 Nakacho, Musashino-shi, + Tokyo 180-8750 Japan + E-mail: Shouichi.Sakane@jp.yokogawa.com, + + + Saber Zrelli + Japan Advanced Institute of Science and Technology + 1-1 Asahidai, Nomi, + Ishikawa 923-1292 Japan + E-mail: zrelli@jaist.ac.jp + + + Masahiro Ishiyama + Toshiba Corporation + 1, komukai-toshiba-cho, Saiwai-ku, + Kawasaki 212-8582 Japan + E-mail: masahiro@isl.rdc.toshiba.co.jp + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + +S.Sakane, et al. [Page 12] + +Internet-Draft July 2007 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +S.Sakane, et al. [Page 13] + -- 2.11.4.GIT