datatracker.ietf.org
Sign in
Version 5.7.1.p2, 2014-10-29
Report a bug

Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials
RFC 5588

Document type: RFC - Proposed Standard (July 2009; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 5588 (Proposed Standard)
Responsible AD: Tim Polk
Send notices to: kitten-chairs@tools.ietf.org, draft-ietf-kitten-gssapi-store-cred@tools.ietf.org

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

   Generic Security Service Application Program Interface (GSS-API)
              Extension for Storing Delegated Credentials

Abstract

   This document defines a new function for the Generic Security Service
   Application Program Interface (GSS-API), which allows applications to
   store delegated (and other) credentials in the implicit GSS-API
   credential store.  This is needed for GSS-API applications to use
   delegated credentials as they would use other credentials.

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.

Table of Contents

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................3
   3. GSS_Store_cred() ................................................3
   4. C-Bindings ......................................................5
   5. Examples ........................................................6
   6. Security Considerations .........................................6
   7. Normative References ............................................7

Williams                    Standards Track                     [Page 1]
RFC 5588                    GSS_Store_cred()                   July 2009

1.  Introduction

   The GSS-API [RFC2743] clearly assumes that credentials exist in an
   implicit store whence they can be acquired using GSS_Acquire_cred()
   and GSS_Add_cred() or through use of the default credential.
   Multiple credential stores may exist on a given host, but only one
   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
   given time.

   This assumption can be seen in Sections 1.1.1.2 and 1.1.1.3 of
   [RFC2743] as well as in Section 3.5 of [RFC2744].

   Applications may be able to change the credential store from which
   credentials can be acquired, either by changing user contexts (where
   the applications have the privilege to do so) or by other means
   (where a user may have multiple credential stores).

   Some GSS-API acceptor applications always change user contexts, after
   accepting a GSS-API security context and making appropriate
   authorization checks, to the user context corresponding to the
   initiator principal name or to a context requested by the initiator.
   The means by which credential stores are managed are generally beyond
   the scope of the GSS-API.

   In the case of delegated credential handles however, such credentials
   do not exist in the acceptor's credential store or in the credential
   stores of the user contexts to which the acceptor application might
   change.  The GSS-API provides no mechanism by which delegated
   credential handles can be made available for acquisition through
   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
   any credential import/export interfaces like the GSS-API context
   import/export interfaces.

   Thus, acceptors are limited to making only direct use of delegated
   credential handles and only with GSS_Init_sec_context(),
   GSS_Inquire_cred*(), and GSS_Release_cred().  This limitation is
   particularly onerous on Unix systems where a call to exec() to
   replace the process image obliterates any delegated credentials
   handle that may exist in that process.

   In order to make delegated credentials generally as useful as
   credentials that can be acquired with GSS_Acquire_cred() and
   GSS_Add_cred(), a primitive is needed that allows storing of
   credentials in the implicit credential store.  We call this primitive
   "GSS_Store_cred()".

Williams                    Standards Track                     [Page 2]
RFC 5588                    GSS_Store_cred()                   July 2009

2.  Conventions Used in This Document

[include full document text]