Network Working Group T. Yu
Internet-Draft MIT Kerberos Consortium
Intended status: Informational July 12, 2010
Expires: January 13, 2011
Desired changes to the GSS-API
draft-yu-kitten-api-wishlist-01
Abstract
Feedback from GSS-API implementors and application developers
suggests that the API as it currently exists would benefit from
improvements. This memo collects some specific suggestions of KITTEN
WG participants.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 13, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Yu Expires January 13, 2011 [Page 1]
Internet-Draft Desired changes to the GSS-API July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Asynchronous calls . . . . . . . . . . . . . . . . . . . . . . 4
3. Error message reporting . . . . . . . . . . . . . . . . . . . . 5
4. Security strength reporting . . . . . . . . . . . . . . . . . . 6
5. Programmer friendliness . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Yu Expires January 13, 2011 [Page 2]
Internet-Draft Desired changes to the GSS-API July 2010
1. Introduction
Experiences of GSS-API implementors and GSS-API application
developers, particularly with the C bindings, suggest that the GSS-
API would benefit from certain improvements. Some of these
suggestions collected from the KITTEN working group include:
1. initialization/new credentials
2. listing/iterating credentials
3. exporting/importing credentials
4. error message reporting
5. asynchronous calls
6. security strength reporting
7. programmer friendliness
This summary is not complete; it is meant as a starting point.
Yu Expires January 13, 2011 [Page 3]
Internet-Draft Desired changes to the GSS-API July 2010
2. Asynchronous calls
The desire for supporting asynchronous calls is a specific case of a
generally accepted goal of increasing concurrency. Proponents of
this goal typically note that new computers appear to be gaining more
processor cores faster than they are gaining computing speed per
core. Asynchronous calls (or event-based solutions) are an
alternative to the traditional multi-threading model for increasing
concurrency.
The existing C bindings say nothing about thread safety for the GSS-
API. Implementors have considered various interpretations of thread
safety, including using internal mutex locks within a GSS-API
implementation to provide thread safety for callers. While the
existing C bindings allow for such an approach, the traditional
threaded programming model has its drawbacks.
In addition, some GSS-API mechanisms are nearly impossible to
implement in a way that prevents gss_init_sec_context and such from
blocking on I/O operations, particularly network I/O. An application
that attempts to achieve high concurrency must dedicate a thread for
each context establishment operation, for example. This can be
problematic on platforms where threads are expensive.
Forcing callers to call into an event loop provided by GSS-API is not
desirable.
Yu Expires January 13, 2011 [Page 4]
Internet-Draft Desired changes to the GSS-API July 2010
3. Error message reporting
Existing GSS-API facilities for obtaining error information are
limited to 32-bit major and minor status codes. This prevents
callers from obtaining detailed (perhaps textual) information that
may assist in troubleshooting. In addition, the existing GSS-API
specifications do not have provisions for gracefully dealing with
potentially conflicting minor status codes in multi-mechanism
implementations, particularly ones that allow for runtime loading of
GSS-API mechanisms.
Concrete approaches for improving GSS-API error reporting appear to
be somewhat lacking, apart from the "PGSSAPI" proposal by Nico
Williams, which adds semantics to the actual pointer value passed as
the minor_context argument. Several working group participants find
the "PGSSAPI" approach distasteful.
Yu Expires January 13, 2011 [Page 5]
Internet-Draft Desired changes to the GSS-API July 2010
4. Security strength reporting
There is some interest in adding an interface to report the security
strength of the established context, for use with implementations of
protocols such as SASL. Some debate has taken place about whether a
numeric report of security strength is an appropriate means of
communicating this information to an application.
Yu Expires January 13, 2011 [Page 6]
Internet-Draft Desired changes to the GSS-API July 2010
5. Programmer friendliness
In the GSS-API C bindings, the gss_accept_sec_context function takes
11 parameters, and the gss_init_sec_context function takes 13. Many
of these parameters accept a default value, and in fact application
developers sometimes unnecessarily provide non-default values, which
often unintentionally results in reduced functionality.
Some programmers find that needing to explicitly loop over
gss_init_sec_context and gss_accept_sec_context (as is currently
required by a conforming GSS-API application during context
establishment) is cumbersome. It may be beneficial to define a
simpler interface for programmers who do not require the additional
control afforded by explicitly calling the context establishment
functions in a loop.
Yu Expires January 13, 2011 [Page 7]
Internet-Draft Desired changes to the GSS-API July 2010
6. Security Considerations
Addition of an interface to report security strength of a GSS-API
context enables applications to make better-informed decisions about
security policy.
Yu Expires January 13, 2011 [Page 8]
Internet-Draft Desired changes to the GSS-API July 2010
Author's Address
Tom Yu
MIT Kerberos Consortium
77 Massachusetts Ave
Building W92 Room 145
Cambridge, MA 02139
US
Phone: +1 617 253 1753
Email: tlyu@mit.edu
Yu Expires January 13, 2011 [Page 9]