draft-ietf-kitten-gssapi-naming-exts-05.txt   draft-ietf-kitten-gssapi-naming-exts-06.txt 
KITTEN WORKING GROUP N. Williams KITTEN WORKING GROUP N. Williams
Internet-Draft Sun Internet-Draft Sun
Intended status: Standards Track L. Johansson Intended status: Standards Track L. Johansson
Expires: January 31, 2010 SUNET Expires: September 8, 2010 SUNET
July 30, 2009 March 7, 2010
GSS-API Naming Extensions GSS-API Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts-06.txt
Abstract
The Generic Security Services API (GSS-API) provides a simple naming
architecture that supports name-based authorization. This document
introduces new APIs that extend the GSS-API naming model to support
name attribute transfer between GSS-API peers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 31, 2010. This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Generic Security Services API (GSS-API) provides a simple naming described in the BSD License.
architecture that supports name-based authorization. This document
introduces new APIs that extend the GSS-API naming model to support
name attribute transfer between GSS-API peers.
Table of Contents Table of Contents
1. Conventions used in this document . . . . . . . . . . . . 3 1. Conventions used in this document . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
3. Name Attribute Authenticity . . . . . . . . . . . . . . . 3 3. Name Attribute Authenticity . . . . . . . . . . . . . . . 3
4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4
5. Attribute Name Syntax . . . . . . . . . . . . . . . . . . 4 5. Attribute Name Syntax . . . . . . . . . . . . . . . . . . 4
6. Mapping Mechanism Facilities to Name Attributes . . . . . 5 6. Mapping Mechanism Facilities to Name Attributes . . . . . 4
6.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 5 6.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 5
6.2. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2.1. Standard PKIX Certificate Extensions . . . . . . . . . . . 5 6.2.1. Standard PKIX Certificate Extensions . . . . . . . . . . . 5
6.2.2. Other PKIX Certificate Extensions and Attributes . . . . . 6 6.2.2. Other PKIX Certificate Extensions and Attributes . . . . . 5
6.3. SAML attribute assertions . . . . . . . . . . . . . . . . 6 6.3. SAML attribute assertions . . . . . . . . . . . . . . . . 6
7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6 7.1. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6
7.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7
7.2. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7 7.2. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7
7.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8 7.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8 7.3. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8
7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9
7.4. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 10 7.4. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 9
7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10
7.5. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11 7.5. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11
7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11
7.6. GSS_Export_name_composite() . . . . . . . . . . . . . . . 12 7.6. GSS_Export_name_composite() . . . . . . . . . . . . . . . 11
7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
7.7. GSS_Map_name_to_any() . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 12
7.7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . 12
7.8. GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . 13
7.8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] . document are to be interpreted as described in [RFC2119] .
2. Introduction 2. Introduction
As described in [I-D.GSS-NAMING] the GSS-API's naming architecture As described in [I-D.GSS-NAMING] the GSS-API's naming architecture
suffers from certain limitations. This document proposes concrete suffers from certain limitations. This document proposes concrete
GSS-API extensions as outlined in [I-D.GSS-NAMING]. GSS-API extensions as outlined in [I-D.GSS-NAMING].
A number of extensions to the GSS-API [RFC2743] and its C Bindings A number of extensions to the GSS-API [RFC2743] and its C Bindings
[RFC2744] are described herein. The goal is to make information [RFC2744] are described herein. The goal is to make information
modeled as "name attributes" available to applications. Such modeled as "name attributes" available to applications. Such
information MAY for instance be used by applications to make information MAY for instance be used by applications to make
authorization-decisions. For example, Kerberos V authorization data authorization-decisions. For example, Kerberos V authorization data
elements, both, in their raw forms as well as mapped to more useful elements, both in their raw forms, as well as mapped to more useful
value types, can be made available to GSS-API applications through value types, can be made available to GSS-API applications through
these interfaces. these interfaces.
The model is that GSS names have attributes. The attributes of a The model is that GSS names have attributes. The attributes of a
name may be authenticated (eg an X509 attribute certificate or signed name may be authenticated (eg an X509 attribute certificate or signed
SAML attribute assertion), or may have been set on a GSS name for the SAML attribute assertion), or may have been set on a GSS name for the
purpose of locally "asserting" the attribute during credential purpose of locally "asserting" the attribute during credential
acquisition or security context exchange. Name attributes' values acquisition or security context exchange. Name attributes' values
are network representations thereof (e.g., the actual value octets of are network representations thereof (e.g., the actual value octets of
the contents of an X.509 certificate extension, for example) and are the contents of an X.509 certificate extension, for example) and are
skipping to change at page 4, line 4 skipping to change at page 4, line 4
An attribute is 'authenticated' iff there is a secure association An attribute is 'authenticated' iff there is a secure association
between the attribute (and its values) and the trusted source of the between the attribute (and its values) and the trusted source of the
peer credential. Examples of authenticated attributes are (any part peer credential. Examples of authenticated attributes are (any part
of) the signed portion of an X.509 certificate or AD-KDCIssued of) the signed portion of an X.509 certificate or AD-KDCIssued
authorization-data elements in Kerberos V Tickets provided of course authorization-data elements in Kerberos V Tickets provided of course
that the authenticity of the respective security associations (eg that the authenticity of the respective security associations (eg
signatures) have been verified. signatures) have been verified.
Note that the fact that an attribute is authenticated does not imply Note that the fact that an attribute is authenticated does not imply
anything about the semantics of the attribute nor that the trusted anything about the semantics of the attribute nor that the trusted
credential source authorized any one semantic of the attribute. Such credential source was authorized to assert the attribute. Such
interpretations MAY be the result of applying local policy to the interpretations SHOULD be the result of applying local policy to the
attribute. attribute.
An un-authentciated attribute is called _asserted_ in what An un-authentciated attribute is called _asserted_ in what
follows.This is not to be confused with other uses of the word follows.This is not to be confused with other uses of the word
asserted or assertion eg "SAML attribute assertion", the attributes asserted or assertion eg "SAML attribute assertion", the attributes
of which may be authenticated in the sense of this document if the of which may be authenticated in the sense of this document for
SAML attribute assertion was signed by a key trusted by the peer. instance if the SAML attribute assertion was signed by a key trusted
by the peer.
4. Name Attributes/Values as ACL Subjects 4. Name Attributes/Values as ACL Subjects
Some name attributes (e.g., numeric user or group identifiers) may be
useful as subjects of access control list (ACL) entries, some may not
(e.g., time of day login restrictions). The
GSS_Inquire_name_attribute() function indicates this.
To facilitate the development of portable applications that make use To facilitate the development of portable applications that make use
of name attributes to construct and evaluate portable ACLs the GSS- of name attributes to construct and evaluate portable ACLs the GSS-
API makes name attribute values available in canonical network API makes name attribute values available in canonical network
encodings thereof. encodings thereof.
To facilitate the development of platform- or language-specific
applications that need access to native types of representations of
name attributes an optional facility is provided,
GSS_Map_name_to_any().
5. Attribute Name Syntax 5. Attribute Name Syntax
Attribute names are represented as opaque STRING elements in the API Attribute names are represented as opaque STRING elements in the API
described below. These attribute names have syntax and semantics described below. These attribute names have syntax and semantics
that are understood by the application and by the lower-layer that are understood by the application and by the lower-layer
implementations (some of which are described below). In order to implementations (some of which are described below). In order to
present a consistent namespace to the application and at the same present a consistent namespace to the application and at the same
time impose as few transformation requirements as possible to lower- time impose as few transformation requirements as possible to lower-
layer implementations attribute names SHOULD be URIs. layer implementations attribute names SHOULD be URIs.
Technologies used in lower-layer protocols may of course use Technologies used in lower-layer protocols may of course use
attribute naming that are not based on URIs. Notably X.509 attribute naming that are not based on URIs. Notably X.509
certificates will use OIDs for most naming purposes. In this case certificates will use OIDs for most naming purposes. In this case
OIDs MUST be mapped into URIs. OIDs MUST be mapped into URIs as described in [RFC3001] MUST be used.
If for example the OID 1.2.3 denotes an Extended Key Usage (cf
When mapping entities named by OIDs into this API [RFC3001] MUST be below), the corresponding GSS-API attribute name MUST be represented
used. For example if the OID 1.2.3 denotes an Extended Key Usage, as urn:oid:1.2.3.
the corresponding GSS-API attribute MUST be represented as
urn:oid:1.2.3.
6. Mapping Mechanism Facilities to Name Attributes 6. Mapping Mechanism Facilities to Name Attributes
In this section we describe two important examples of lower-layer In this section we describe two important examples of lower-layer
implementations of this API. These examples are not mandatory to implementations of this API. These examples are not mandatory to
implement and are only provided for reference. The use of [RFC2119]- implement and are only provided for reference. The use of [RFC2119]-
terms in this section is limited to those implementations of the GSS- terms in this section is limited to those implementations of the GSS-
API naming extensions that choose to implement these lower-layer API naming extensions that choose to implement these lower-layer
technologies. technologies. Future mappings SHOULD be documented as RFCs.
Kerberos V [RFC4120] and the Simple Public-Key GSS-API Mechanism, Kerberos V [RFC4120] and the Simple Public-Key GSS-API Mechanism,
SPKM described in [RFC2025], both support the concept and encoding of SPKM described in [RFC2025], both support the concept and encoding of
containers of "authorization-data" as described in [RFC4120]. containers of "authorization-data" as described in [RFC4120].
PKIX [RFC5280] supports a number of attribute-like features, like PKIX [RFC5280] supports a number of attribute-like features, like
Extended Key Usage values (EKUs) and certificate extensions. Extended Key Usage values (EKUs) and certificate extensions.
6.1. Kerberos V and SPKM Authorization-Data 6.1. Kerberos V and SPKM Authorization-Data
Authorization-data non-container elements asserted in Kerberos V AP- Authorization-data non-container elements asserted in Kerberos V AP-
REQ Authenticators MUST be mapped into *asserted* GSS-API name REQ Authenticators MUST be mapped into *asserted* GSS-API name
attributes. attributes.
Authorization-data included in Kerberos V Tickets that is not Authorization-data included in Kerberos V Tickets that is not
contained in AD-KDCIssued (with valid signature) MUST be mapped into contained in AD-KDCIssued (with valid signature) MUST be mapped into
*asserted* GSS-API name attributes. Conversely, authorization-data *asserted* GSS-API name attributes. Conversely, authorization-data
elements in Kerberos V Tickets contained by AD-KDCIssued MUST be elements in Kerberos V Tickets contained by AD-KDCIssued MUST be
mapped into *authenticated* GSS-API name attributes. mapped into *authenticated* GSS-API name attributes.
The URIs for authorization-data elements MUST be the authorization-
data elements 'ad-type' prefixed by the IANA-allocated URN prefix
(<TBD>)
6.2. PKIX 6.2. PKIX
6.2.1. Standard PKIX Certificate Extensions 6.2.1. Standard PKIX Certificate Extensions
PKI certificate extensions MAY/SHOULD/MUST (see comment above) be PKIX certificate extensions MAY/SHOULD/MUST (see comment above) be
represented as *authenticated* GSS-API name attributes named using represented as *authenticated* GSS-API name attributes named using
the _same_. the _same_ OID mapped to a URN.
SubjectAltNames and EKUs, specifically, MUST be represented as
*authenticated* GSS-API name attributes; see below. Certificate
extensions MUST be represented as GSS-API name attributes named using
the OIDs used for the extensions (represented as URNs)
Extended Key Usage extensions, specifically, MUST be mapped as SubjectAltNames and Extended Key Usage OIDs, specifically, MUST be
described above, except that GSS-API name attributes for EKUs MUST represented as *authenticated* GSS-API name attributes; see below.
have NULL values (i.e., zero-length OCTET STRINGs). Certificate extensions MUST be represented as GSS-API name attributes
named using the OIDs used for the extensions (represented as URNs).
The value associated with Extended Key Usage attributes MUST have
NULL value represented as a zero-length OCTET STRING.
PKI certificate key usages (KUs, but not EKUs), MUST NOT be The standard PKIX certificate key usage (KUs, but not EKUs), MUST NOT
represented as GSS-API name attributes. be represented as GSS-API name attributes.
PKI certificate subjectAltNames MUST be mapped as *authenticated*. PKIX certificate subjectAltNames MUST be mapped as *authenticated*
GSS-API name attributes. The values SHOULD be the values of the
subjectAltName represented as OCTET STRINGs if the type of the
subjectAltName supports a unique loss-less representation as string
values. Specifically dnsName, ipAddress, uniformResourceLocator and
emailAddress MUST be returned using the corresponding string
representation of those data types.
6.2.2. Other PKIX Certificate Extensions and Attributes 6.2.2. Other PKIX Certificate Extensions and Attributes
Any X.509 certificate extension not covered above SHOULD be Any X.509 certificate extension not covered above SHOULD be
represented as GSS-AOI name attributes with the OID of the X.509 represented as GSS-API name attributes with the OID of the X.509
extension and with OCTET STRING values containing the encoded value extension and with OCTET STRING values containing the encoded value
of the extension. of the extension.
6.3. SAML attribute assertions 6.3. SAML attribute assertions
Attributes contained in SAML attribute assertions are mapped to GSS- Attributes contained in SAML attribute assertions MUST be mapped to
API name attributes with the same URIs as used in the SAML attribute GSS-API name attributes with the same URIs as used in the SAML
names (subject to representing OIDs to URIs). attribute name.
SAML attributes found in SAML attribute assertions MUST NOT be mapped SAML attributes found in SAML attribute assertions MUST NOT be mapped
as authenticated unless the SAML attribute assertion was signed by a as authenticated unless the SAML attribute assertion was signed by a
key trusted by the peer or otherwise protected from unauthorized key trusted by the peer or otherwise protected from unauthorized
modification. modification.
7. API 7. API
7.1. GSS_Display_name_ext() 7.1. GSS_Display_name_ext()
skipping to change at page 7, line 41 skipping to change at page 7, line 32
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
o minor_status INTEGER, o minor_status INTEGER,
o name_is_MN BOOLEAN, o name_is_MN BOOLEAN,
o mn_mech OBJECT IDENTIFIER, o mn_mech OBJECT IDENTIFIER,
o asserted_attrs SET OF STRING, o attrs SET OF OCTET STRING
o authenticated_attrs SET OF STRING,
o all_attrs SET OF STRING,
Return major_status codes: Return major_status codes:
o GSS_S_COMPLETE indicates no error. o GSS_S_COMPLETE indicates no error.
o GSS_S_FAILURE indicates a general error. o GSS_S_FAILURE indicates a general error.
This function outputs the sets (represented as a NULL terminated This function outputs the set (represented as a NULL terminated array
array of gss_buffer_t) of attributes of a name, that are of gss_buffer_t) of attributes of a name. It also indicates if a
authenticated or asserted. It also indicates if a given NAME is an given NAME is an MN or not and, if it is, what mechanism it's an MN
MN or not and, if it is, what mechanism it's an MN of. of. The gss_buffer_set_t type and associated API is defined in
[GFD.024]
7.2.1. C-Bindings 7.2.1. C-Bindings
OM_uint32 gss_inquire_name( OM_uint32 gss_inquire_name(
OM_uint32 *minor_status, OM_uint32 *minor_status,
gss_name_t name, gss_name_t name,
int name_is_MN, int name_is_MN,
gss_OID *MN_mech, gss_OID *MN_mech,
gss_buffer_t *authenticated, gss_buffer_set_t *attrs
gss_buffer_t *asserted,
gss_buffer_t *all_attrs
); );
7.3. GSS_Get_name_attribute() 7.3. GSS_Get_name_attribute()
Inputs: Inputs:
o name NAME, o name NAME,
o attr STRING o attr STRING
skipping to change at page 9, line 42 skipping to change at page 9, line 29
per-attribute value, for multi-valued name attributes. This is done per-attribute value, for multi-valued name attributes. This is done
by using a single gss_buffer_t for each value and an input/output by using a single gss_buffer_t for each value and an input/output
integer parameter to distinguish initial and subsequent calls and to integer parameter to distinguish initial and subsequent calls and to
indicate when all values have been obtained. indicate when all values have been obtained.
The 'more' input/output parameter should point to an integer variable The 'more' input/output parameter should point to an integer variable
whose value, on first call to gss_name_attribute_get() MUST be -1, whose value, on first call to gss_name_attribute_get() MUST be -1,
and whose value upon function call return will be non-zero to and whose value upon function call return will be non-zero to
indicate that additional values remain, or zero to indicate that no indicate that additional values remain, or zero to indicate that no
values remain. The caller should not modify this parameter after the values remain. The caller should not modify this parameter after the
initial call. initial call. The status of the complete and authenticated flags
MUST NOT change between multiple calls to iterate over values for an
attribute.
OM_uint32 gss_get_name_attribute( OM_uint32 gss_get_name_attribute(
OM_uint32 *minor_status, OM_uint32 *minor_status,
gss_name_t name, gss_name_t name,
gss_buffer_t attr, gss_buffer_t attr,
int *authenticated, int *authenticated,
int *complete, int *complete,
gss_buffer_t value, gss_buffer_t value,
gss_buffer_t display_value, gss_buffer_t display_value,
int *more int *more
skipping to change at page 12, line 46 skipping to change at page 12, line 36
The OID for GSS_C_NT_COMPOSITE_EXPORT is <TBD>. The OID for GSS_C_NT_COMPOSITE_EXPORT is <TBD>.
7.6.1. C-Bindings 7.6.1. C-Bindings
OM_uint32 gss_export_name_composite( OM_uint32 gss_export_name_composite(
OM_uint32 *minor_status, OM_uint32 *minor_status,
gss_name_t name, gss_name_t name,
gss_buffer_t exp_composite_name gss_buffer_t exp_composite_name
); );
7.7. GSS_Map_name_to_any()
Inputs:
o name NAME,
o authenticated BOOLEAN, -- if TRUE only authenticated attributes
will be included
o type_id STRING
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o output ANY DEFINED BY type_id
Return major_status codes:
o GSS_S_COMPLETE indicates no error.
o GSS_S_UNAVAILABLE indicates that the mapping or conversion could
not be done. The minor status code may provide additional
information.
o GSS_S_FAILURE indicates a general error. The minor status code
may provide additional information.
Whereas name attribute's values are encoded in some network
representation applications often require native, language- and/or
platform-specific data types. This function provides access to such
types.
7.7.1. C-Bindings
typedef struct gss_any *gss_any_t;
OM_uint32 gss_map_name_to_any(
OM_uint32 *minor_status,
gss_name_t name,
int authenticated,
gss_buffer_t type_id, // why isn't this 'name'?
gss_any_t output
);
Note the new C bindings type, gss_any_t. We define it as a pointer
to an incompletely declared struct.
7.8. GSS_Release_any_name_mapping()
Inputs:
o name NAME,
o type_id STRING,
o input ANY DEFINED BY type_id
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
Return major_status codes:
o GSS_S_COMPLETE indicates no error.
o GSS_S_UNAVAILABLE indicates that the mapping or conversion could
not be done. The minor status code may provide additional
information.
o GSS_S_FAILURE indicates a general error. The minor status code
may provide additional information.
This function releases, if possible, the objects of language- and/or
platform-specific types output by GSS_Map_name_to_any(). If such
types have native release functions applications MAY use either those
or this function to release the given object.
7.8.1. C-Bindings
typedef struct gss_any *gss_any_t;
OM_uint32 gss_release_any_name_mapping(
OM_uint32 *minor_status,
gss_name_t name,
gss_buffer_t type_id,
gss_any_t *input
);
8. IANA Considerations 8. IANA Considerations
This document creates a namespace of GSS-API name attributes. This document creates a namespace of GSS-API name attributes.
Attributes are named by URIs, so no single authority is technically Attributes are named by URIs, so no single authority is technically
needed for allocation. However future deployment experience may needed for allocation. However future deployment experience may
indicate the need for an IANA registry for URIs used to reference indicate the need for an IANA registry for URIs used to reference
names specified by IETF standards. It is expected that this will be names specified by IETF standards. It is expected that this will be
a registry of URNs but this document provides no further guidance on a registry of URNs but this document provides no further guidance on
this registry. this registry.
9. Security Considerations 9. Security Considerations
This document extends the GSS-API naming model to include support for This document extends the GSS-API naming model to include support for
name attributes. The intention is that name attributes are to be name attributes. The intention is that name attributes are to be
used as a basis for (among other things) authorization decisions or used as a basis for (among other things) authorization decisions or
application personalization for applications relying on GSS-API personalization for applications relying on GSS-API security
security contexts. contexts.
The security of the application may be critically dependent on the The security of the application may be critically dependent on the
security of the attributes. This document classifies attributes as security of the attributes. This document classifies attributes as
asserted or authenticated. Only authenticated attributes MUST be asserted or authenticated. Asserted (non-authenticated) attributes
used if the attribute has security implications for the application MUST NOT be used if the attribute has security implications for the
(eg authorization decisions) since asserted attributes may easily be application (eg authorization decisions) since asserted attributes
controlled by the peer directly. may easily be controlled by the peer directly.
It is important to understand the meaning of 'authenticated' in this It is important to understand the meaning of 'authenticated' in this
setting. It does not mean that any semantic of the attribute is setting. Authenticated does not imply that any semantic of the
claimed to be true. The only implication is that a trusted third attribute is claimed to be true. The only implication is that a
party has asserted the attribute as opposed to the attribute being trusted third party has asserted the attribute as opposed to the
asserte by the peer itself. Any additional semantics is always the attribute being asserte by the peer itself. Any additional semantics
result of applying policy. For instance in a given deployment the is always the result of applying policy. For instance in a given
mail attribute of the subject may be authenticated and sourced from deployment the mail attribute of the subject may be authenticated and
an email system where 'correct' values are kept. In another setting sourced from an email system where 'authoritive' values are kept. In
users may be allowed to modify their mail addresses freely. In both another situations users may be allowed to modify their mail
cases the 'mail' attribute may be authenticated by virtue of being addresses freely. In both cases the 'mail' attribute may be
included in signed SAML attribute assertions lor by other means authenticated by virtue of being included in signed SAML attribute
authenticated by the underlying mechanism. assertions or by other means authenticated by the underlying
mechanism.
When the underlying security mechanism does not provide a permanent When the underlying security mechanism does not provide a permanent
unique identity (eg anonymous kerberos) the GSS-API naming extensions unique identity (eg anonymous kerberos) the GSS-API naming extensions
may be used to provide a replacement permanent unique identity may be used to provide a replacement permanent unique identity
attribute which in this case may be unique for each relying party. attribute which in this case may be unique for each peer party. This
This is analogous to the Liberty Alliance targetedID attribute and is analogous to the SAML permanentIdentifier attribute and has
has similar security implications. comparable security and privacy properties and implications.
10. Normative References 10. References
[I-D.GSS-NAMING] 10.1. Normative References
Hartman, S., "Desired Enhancements to GSSAPI Naming",
draft-ietf-kitten-gss-naming-01.txt (work in progress), [GFD.024] Argonne National Laboratory, National Center for
February 2005. Supercomputing Applications, Argonne National Laboratory,
and Argonne National Laboratory, "GSS-API Extensions",
GFD GFD.024, June 2004.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996. (SPKM)", RFC 2025, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
skipping to change at page 16, line 29 skipping to change at page 14, line 23
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
10.2. Informative References
[I-D.GSS-NAMING]
Hartman, S., "Desired Enhancements to GSSAPI Naming",
draft-ietf-kitten-gss-naming-01.txt (work in progress),
February 2005.
Authors' Addresses Authors' Addresses
Nicolas Williams Nicolas Williams
Sun Microsystems Sun Microsystems
5300 Riata Trace Ct 5300 Riata Trace Ct
Austin, TX 78727 Austin, TX 78727
US US
Email: Nicolas.Williams@sun.com Email: Nicolas.Williams@sun.com
 End of changes. 38 change blocks. 
201 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/