Extended Generic Security Service Mechanism Inquiry APIs
RFC 5587

Network Working Group                                        N. Williams
Request for Comments: 5587                                           Sun
Category: Standards Track                                      July 2009

        Extended Generic Security Service Mechanism Inquiry APIs

Abstract

   This document introduces new application programming interfaces
   (APIs) to the Generic Security Services API (GSS-API) for extended
   mechanism attribute inquiry.  These interfaces are primarily intended
   to reduce instances of hardcoding of mechanism identifiers in GSS
   applications.

   These interfaces include mechanism attributes and attribute sets, a
   function for inquiring the attributes of a mechanism, a function for
   indicating mechanisms that possess given attributes, and a function
   for displaying mechanism attributes.

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Williams                    Standards Track                     [Page 1]
RFC 5587               Extended GSS Mech Inquiry               July 2009

Table of Contents

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................2
   3. New GSS-API Interfaces ..........................................3
      3.1. Mechanism Attributes and Attribute Sets ....................3
      3.2. List of Known Mechanism Attributes .........................4
      3.3. Mechanism Attribute Sets of Existing Mechs .................6
      3.4. New GSS-API Function Interfaces ............................8
           3.4.1. Mechanism Attribute Criticality .....................8
           3.4.2. GSS_Indicate_mechs_by_attrs() .......................9
           3.4.3. GSS_Inquire_attrs_for_mech() .......................10
           3.4.4. GSS_Display_mech_attr() ............................10
           3.4.5. New Major Status Values ............................11
           3.4.6. C-Bindings .........................................11
   4. Requirements for Mechanism Designers ...........................13
   5. IANA Considerations ............................................13
   6. Security Considerations ........................................13
   7. References .....................................................13
      7.1. Normative References ......................................13
      7.2. Informative References ....................................14
Appendix A. Typedefs and C Bindings ..................................15

1.  Introduction

   GSS-API [RFC2743] mechanisms have a number of properties that may be
   of interest to applications.  The lack of APIs for inquiring about
   available mechanisms' properties has meant that many GSS-API
   applications must hardcode mechanism Object Identifiers (OIDs).
   Ongoing work may result in a variety of new GSS-API mechanisms.
   Applications should not have to hardcode their OIDs.

   For example, the Secure Shell version 2 (SSHv2) protocol [RFC4251]
   supports the use of GSS-API mechanisms for authentication [RFC4462]
   but explicitly prohibits the use of Simple and Protected GSS-API
   Negotiation (SPNEGO) [RFC4178].  Future mechanisms that negotiate
   mechanisms would have to be forbidden as well, but there is no way to
   implement applications that inquire what mechanisms are available and
   then programmatically exclude mechanisms "like SPNEGO".

2.  Conventions Used in This Document

   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].

Williams                    Standards Track                     [Page 2]
RFC 5587               Extended GSS Mech Inquiry               July 2009

3.  New GSS-API Interfaces