DMTF Change Request

DMTF Confidential

Background/Rationale (Explanation of the background and reason(s) for the requested change, and supporting documentation):

Existing implementations are looking at adding additional types of authentication to CIM.  Currently only Basic and Digest authentication are specified as standard types of authentication for CIM clients, CIM servers and CIM listeners.  Basic authentication essentially sends passwords in the clear, while Digest authentication can not be supported on platforms that don't maintain a clear-text password.  Because Kerberos authentication is a standard in the industry and is supported by nearly every platform as well as a growing number of applications, this CR is being proposed to include Kerberos as a standard authentication type for CIM.
 

Requested Change (Change information such as details before/after the change, readable/indented MOF, and/or references to "Uploaded" MOF and other documents if the changes are too lengthy to include inline):

In section 4.4 Security Considerations, add to the 2nd paragraph "Kerberos Authentication is described in [22,23,24]."  Note to readers:  those references are described later in this section - if the reference numbers change when they are added to the actual specification, these reference numbers must change accordingly.

In the 5th paragraph, change the sentence "Conforming applications SHOULD support the Digest authentication scheme." to "Conforming applications SHOULD support the Digest authentication or Kerberos authentication scheme."   Also, add a sentence "Kerberos Authentication is preferable to either Basic or Digest Authentication in terms of security because the Kerberos ticket, not a disguised password, is sent to the CIM component."

The 6th paragraph should have two sentences added as follows:  "CIM Clients, CIM Servers and CIM Listeners using Kerberos Authentication MUST comply with the requirements set forth in [22,23].  Many platforms provide Kerberos authentication via the use of the Generic Security Service (GSS) Application Programming Interface (API) as described in [24]." between the sentence about Basic or Digest Authentication and the sentence about this specification describes only additional requirements...
 

In the last paragraph the sentence "A CIM Server or CIM Listener that returns a "401 Unauthorized" response to a CIM Message Request SHOULD include in the WWW-Authenticate response-header either the "Basic" or "Digest" authentication values (but not both).   This specification does not mandate use of Basic or Digest Authentication as it is recognized that in come circumstances the CIM Server or CIM Listener MAY use bespoke authentication mechanisms not covered by [14]." should be changed to "A CIM Server or CIM Listener that returns a "401 Unauthorized" response to a CIM Message Request SHOULD include in the WWW-Authenticate response-header either the "Basic" or "Digest" or "Negotiate" authentication values (but only one).   This specification does not mandate use of Basic, Digest or Kerberos Authentication as it is recognized that in come circumstances the CIM Server or CIM Listener MAY use bespoke authentication mechanisms not covered by [14] or [22,23,24]."

Add a subsection, 4.4.1 Additional Requirements for Kerberos Authentication, as follows:  "In order for the CIM server or CIM listener to be Kerberos enabled it must be registered with the Kerberos Key Distribution Center (KDC) as a CIMOM or CIMLISTENER service principal to which a user can get a Kerberos service ticket.  The standard CIMOM service principal for the CIM server is recommended to be "cimom/<HOST_NAME>@REALM" where the HOST_NAME is the name of the system on which the CIMOM server is running, and REALM is described in [23].  The standard CIMLISTENER service principal for the CIM listener is recommended to be "cimlistener/<HOST_NAME>@REALM" where the HOST_NAME is the name of the system on which the CIM Listener server is running, and REALM is described in [23]."  Use of Kerberos for indication consumer connections requires each CIM Listener must be registered in the KDC, and the CIMOM Server must have extra setup in the form of a password in a keytab file that is used to authenticate the CIM Server to the KDC and obtain a service ticket for the CIM Listener service.  There is no authentication-type relationship between the CIM Client / CIM Server connection where the indication subscription was created, and the CIM Server / CIM Listener connection for the indication consumer.
 

Section 5 References should have these references added:

22.  "HTTP Authentication:  SPNEGO Access Authentication As implemented in Microsoft Windows 2000", Kerberos working group Internet Draft, February 2002 http://www.faqs.org/ftp/internet-drafts/draft-brezak-spnego-http-03.txt

23.  "The Kerberos Network Authentication Service (V5)", IETF RFC 1510, September 1993 http://www.ietf.org/rfc/rfc1510.txt?number=1510

24.  "The Kerberos Version 5 GSS-API Mechanism", IETF RFC 1964, June 1996 http://www.ietf.org/rfc/rfc1964.txt?number=1964
 
 

Discussion Points (Summary of decisions and discussions of the WG in creating this CR):

<Discussions and decisions made within the WG and/or TC>
 

Change History (Mandatory after submission to the TC, May be used by the WGs):
 
 

Initial Version	05/20/2003	Initial submission
Version "a"	<Date>	<Changes>

Terminology

The key phrases and 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 the IETF's RFC 2119.The complete reference for this document is: "Key words for Use in RFCs to Indicate Requirement Levels", IETF RFC 2119, March 1997 (http://www.ietf.org/rfc/rfc2119.txt).
 

Notes

This document is labeled as "DMTF Confidential". It is intended only for DMTF member companies and alliance partners.

This Change Request may be withdrawn or modified by subsequent CRs.