draft-ietf-kitten-gssapi-naming-exts-02.txt   draft-ietf-kitten-gssapi-naming-exts-03.txt 
NETWORK WORKING GROUP N. Williams
KITTEN WORKING GROUP N. Williams
Internet-Draft Sun Internet-Draft Sun
Expires: December 28, 2006 June 26, 2006 Intended status: Standards Track L. Johansson
Expires: January 14, 2009 Stockholm university
July 13, 2008
GSS-API Naming Extensions GSS-API Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-02.txt draft-ietf-kitten-gssapi-naming-exts-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 32 skipping to change at page 1, line 35
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 December 28, 2006. This Internet-Draft will expire on January 14, 2009.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract Abstract
The Generic Security Services API (GSS-API) provides a simple naming The Generic Security Services API (GSS-API) provides a simple naming
architecture that supports name-based authorization. This document architecture that supports name-based authorization. This document
introduces new APIs that extend the GSS-API naming and authorization introduces new APIs that extend the GSS-API naming model to support
model. 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 Sources and Criticality . . . . . . . . . . 3 3. Name Attribute Sources and Criticality . . . . . . . . . . 3
4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4
5. Mapping Mechanism Facilities to Name Attributes . . . . . 4 5. Mapping Mechanism Facilities to Name Attributes . . . . . 4
5.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 4 5.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 5
5.2. Kerberos V Cross-Realm Transit Paths . . . . . . . . . . . 5 5.2. PKIX Certificate Extensions . . . . . . . . . . . . . . . 5
5.3. PKIX Certificate Extensions . . . . . . . . . . . . . . . 5 5.2.1. PKIX EKUs . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3.1. PKIX EKUs . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2.2. PKIX Certificate Alternative Names . . . . . . . . . . . . 6
5.3.2. PKIX Certificate Alternative Names . . . . . . . . . . . . 6 5.2.3. Other PKIX Certificate Extensions and Attributes . . . . . 6
5.3.3. Other PKIX Certificate Extensions and Attributes . . . . . 6 5.2.4. SAML attribute assertions . . . . . . . . . . . . . . . . 6
5.4. PKIX Certificate CA Paths and Trust Anchors . . . . . . . 6
6. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6 6. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6
6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7
7. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7 7. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7
7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8
8. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8 8. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8
8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9
9. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 10 9. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 10
9.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11
10. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11 10. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11
10.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
11. GSS_Export_name_composite() . . . . . . . . . . . . . . . 12 11. GSS_Export_name_composite() . . . . . . . . . . . . . . . 12
11.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13
12. GSS_Map_name_to_any() . . . . . . . . . . . . . . . . . . 13 12. GSS_Map_name_to_any() . . . . . . . . . . . . . . . . . . 13
12.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13
13. GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 14 13. GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 14
13.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15
14. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 15
15. Security Considerations . . . . . . . . . . . . . . . . . 15 15. Security Considerations . . . . . . . . . . . . . . . . . 15
16. Normative References . . . . . . . . . . . . . . . . . . . 15 16. Normative References . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . 19
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 with the goal of making authorization [RFC2744] are described herein with the goal of making authorization
information, and other information that can be modelled as "name information, and other information that can be modeled as "name
attributes" available as such to applications. For example, Kerberos attributes" available as such to applications. For example, Kerberos
V authorization data elements, both, in their raw forms as well as V authorization data elements, both, in their raw forms as well as
mapped to more useful value types, can be made available to GSS-API mapped to more useful value types, can be made available to GSS-API
applications through these interfaces. applications through 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 by the credential whence the name comes, or name may be authenticated by the credential whence the name comes, or
may have been set locally on a GSS name for the purpose of may have been set locally on a GSS name for the purpose of
"asserting" the attribute during credential acquisition or security "asserting" the attribute during credential acquisition or security
context exchange. Name attributes' values are network context exchange. Name attributes' values are network
representations thereof (e.g., the actual value octets of the representations thereof (e.g., the actual value octets of the
contents of an X.509 certificate extension, for example) and are contents of an X.509 certificate extension, for example) and are
intended to be useful for constructing portable access control intended to be useful for constructing portable access control
facilities. Applications may often require language- or platform- facilities. Applications may often require language- or platform-
specific data types, rather than network representations of name specific data types, rather than network representations of name
attributes, so a function is provided to obtain objects of such types attributes, so a function is provided to obtain objects of such types
associated with names and name attributes. associated with names and name attributes.
3. Name Attribute Sources and Criticality 3. Name Attribute Sources and Criticality
A given GSS name object's name attributes may be authenticated or A given GSS name object's name attributes may be authenticated,
asserted by an associated credential, or it may be mapped or derived mapped and/or critical. These flags are explained below.
from another attribute of the same name.
An attribute is 'authenticated' iff there is a secure association
between the attribute (and its values) and the trusted source of the
peer credential. Examples of authenticated attributes are (any part
of) the signed portion of an X.509 certificate or AD-KDCIssued
authorization-data elements in Kerberos V Tickets. Note that the
fact that an attribute is authenticated does not imply anything about
the semantics of the attribute nor that the trusted credential source
authorized any one semantic of the attribute. Such interpretations
MAY be the result of applying local policy to the attribute.
That a given name's given attribute is 'mapped' means that it was That a given name's given attribute is 'mapped' means that it was
obtained through some mapping mechanism applied to another attribute obtained through some mapping mechanism applied to another attribute
of the name that was not, itself, mapped. For example, such of the name that was not, itself, mapped. For example, such
attributes as platform-specific internal identifiers may sometimes be attributes as platform-specific internal identifiers may sometimes be
mapped from other name attributes. mapped from other name attributes.
Name attributes may be "critical," meaning that applications that do Name attributes may be "critical," meaning that applications that do
not understand them MUST reject security contexts where the peer has not understand them MUST reject security contexts where the peer has
such unknown, critical attributes. such unknown, critical attributes.
[NOTE(leifj): The criticality flag seems to have limited
applicability in practice. As written the security context should
not be established unless all critically marked naming attributes are
supported and understood. But what happens if the peer doesn't
understand naming extensions at all. It seems more reasonable to
state that name attribute extensions MUST only be used to as a basis
for authorization decisions.]
[NOTE(leifj): The mapped flag also seems to have limited
applicability in practice - interpretation of the attribute will be
entierly up to the peer anyway which will need to know much more
about the attribute than the fact than its value is derived.]
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 Some name attributes (e.g., numeric user or group identifiers) may be
useful as subjects of access control list (ACL) entries, some may not useful as subjects of access control list (ACL) entries, some may not
(e.g., time of day login restrictions). The (e.g., time of day login restrictions). The
GSS_Inquire_name_attribute() function indicates this. 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
skipping to change at page 5, line 17 skipping to change at page 5, line 39
*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
As with authorization-data elements in Authenticators, authorization- As with authorization-data elements in Authenticators, authorization-
data elements in Tickets not contained in AD-IF-RELEVANT are to be data elements in Tickets not contained in AD-IF-RELEVANT are to be
mapped to *critical* name attributes, and similarly with AD-AND-OR mapped to *critical* name attributes, and similarly with AD-AND-OR
(see above). (see above).
The OIDs for authorization-data elements are to be the authorization- The OIDs for authorization-data elements are to be the authorization-
data element's 'ad-type' integer ID, relative to the base OID <TBD> data element's 'ad-type' positive integer ID, relative to the base
[NOTE: what about negative ad-type's? OID arcs are positive OID <TBD> Negative values are reserved for local experiments. [NOTE:
integers... ad-type is an Int32, so clearly something can be done.] what about negative ad-type's? OID arcs are positive integers... ad-
type is an Int32, so clearly something can be done.]
5.2. Kerberos V Cross-Realm Transit Paths
[Add text on how to represent/encode/interpret krb5 realm transit
paths as name attribute values. And text on PKINIT too... Basically
Ticket's 'transited' field should be exposed as an authenticated name
attribute, with some uncompressed encoding, possibly encompassing
certificate validation paths of client certs used for PKINIT, with
criticality determined by the presence of the transit-policy-checked
flag.]
5.3. PKIX Certificate Extensions
[NOTE: In the Kerberos V authorization-data case we can tell when AD 5.2. PKIX Certificate Extensions
elements are "authenticated" and when the are asserted, but what
about x.509 certificate extensions? Clearly KU, EKUs and
subjectAltNames are authenticated in that no CA should sign a cert
with, say, arbitrary subjectAltNames not understood by the CA, but,
does that also apply to all other x.509 certificate extensions? The
answer may depend on actual CA operator practices... At worst a new
extension may be needed, like Kerberos V's AD-KDCIssued AD container
element; at best this text can just say "all cert extensions MUST be
mapped to authenticated..." below.]
PKI certificate extensions MAY/SHOULD/MUST (see comment above) be PKI certificate extensions MAY/SHOULD/MUST (see comment above) be
mapped to *authenticated* GSS-API name attributes with the _same_ represented as *authenticated* GSS-API name attributes with the
OIDs, and if they be marked critical in the certificate then they _same_ OIDs, and if they be marked critical in the certificate then
MUST be mapped as *critical* GSS-API name attributes. they MUST be mapped as *critical* GSS-API name attributes.
SubjectAltNames and EKUs, specifically, MUST be mapped to SubjectAltNames and EKUs, specifically, MUST be represented as
*authenticated* GSS-API name attributes; see below. Certificate *authenticated* GSS-API name attributes; see below. Certificate
extensions MUST be mapped to GSS-API name attributes whose OIDs are extensions MUST be represented as GSS-API name attributes whose OIDs
the same as the extensions' are the same as the extensions'
5.3.1. PKIX EKUs 5.2.1. PKIX EKUs
Extended Key Usage extensions, specifically, MUST be mapped as Extended Key Usage extensions, specifically, MUST be mapped as
described above, except that GSS-API name attributes for EKUs MUST described above, except that GSS-API name attributes for EKUs MUST
have NULL values (i.e., zero-length OCTET STRINGs). have NULL values (i.e., zero-length OCTET STRINGs).
PKI certificate key usages (KUs, but not EKUs), MUST NOT be mapped to PKI certificate key usages (KUs, but not EKUs), MUST NOT be
GSS-API name attributes. represented as GSS-API name attributes.
5.3.2. PKIX Certificate Alternative Names 5.2.2. PKIX Certificate Alternative Names
PKI certificate subjectAltNames MUST be mapped as *authenticated*, PKI certificate subjectAltNames MUST be mapped as *authenticated*,
*non-critical* GSS-API name attributes. *non-critical* GSS-API name attributes.
PKI certificate extensions MUST be mapped to *authenticated* GSS-API PKI certificate extensions MUST be represented as *authenticated*
name attributes with the _same_ OIDs, and if they be marked critical GSS-API name attributes with the _same_ OIDs, and if they be marked
in the certificate then they MUST be mapped as *critical* GSS-API critical in the certificate then they MUST be mapped as *critical*
name attributes. GSS-API name attributes.
Extended Key Usage extensions, specifically, MUST be mapped as Extended Key Usage extensions, specifically, MUST be mapped as
described above, except that GSS-API name attributes for EKUs MUST described above, except that GSS-API name attributes for EKUs MUST
have NULL values (i.e., zero-length OCTET STRINGs). have NULL values (i.e., zero-length OCTET STRINGs).
5.3.3. Other PKIX Certificate Extensions and Attributes 5.2.3. Other PKIX Certificate Extensions and Attributes
[Add text...] Any X.509 certificate extension not covered above SHOULD be
represented as GSS-AOI name attributes with the OID of the X.509
extension and with OCTET STRING values containing the encoded value
of the extension.
5.4. PKIX Certificate CA Paths and Trust Anchors 5.2.4. SAML attribute assertions
[Add text on how to represent/encode/interpret PKI certificate Attributes contained in SAML attribute assertions are mapped to GSS-
validation CA paths as name attribute values, much as with Kerberos V API name attributes with OIDs derived from the SAML attributes:
transited paths.]
If the SAML attribute is an OID the same OID is used.
If the SAML attribute is a URN or a URI then the name MUST be
mapped to a corresponding OID by means of an IANA registry.
6. GSS_Display_name_ext() 6. GSS_Display_name_ext()
Inputs: Inputs:
o name NAME, o name NAME,
o display_as_name_type OBJECT IDENTIFIER o display_as_name_type OBJECT IDENTIFIER
Outputs: Outputs:
skipping to change at page 8, line 4 skipping to change at page 8, line 14
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 OBJECT IDENTIFIER, o asserted_attrs SET OF OBJECT IDENTIFIER,
o authenticated_attrs SET OF OBJECT IDENTIFIER, o authenticated_attrs SET OF OBJECT IDENTIFIER,
o critical_attrs SET OF OBJECT IDENTIFIER, o critical_attrs SET OF OBJECT IDENTIFIER,
o all_attrs SET OF OBJECT IDENTIFIER, o all_attrs SET OF OBJECT IDENTIFIER,
o [NOTE: Perhaps this function should also output an indicator as to
the provenance of the name, of which, in the GSS-API, there are
three: imported, inquired from a credential, and a peer's name
inquired from a security context.]
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 of attributes of a name, that are This function outputs the sets of attributes of a name, that are
authenticated, asserted or critical. It also indicates if a given authenticated, asserted or critical. It also indicates if a given
NAME is an MN or not and, if it is, what mechanism it's an MN of. NAME is an MN or not and, if it is, what mechanism it's an MN of.
skipping to change at page 8, line 45 skipping to change at page 9, line 4
gss_OID_set *all_attrs gss_OID_set *all_attrs
); );
8. GSS_Get_name_attribute() 8. GSS_Get_name_attribute()
Inputs: Inputs:
o name NAME, o name NAME,
o attr OBJECT IDENTIFIER o attr OBJECT IDENTIFIER
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
o minor_status INTEGER, o minor_status INTEGER,
o authenticated BOOLEAN, -- FALSE if asserted but not authenticated o authenticated BOOLEAN, -- TRUE iff authenticated by the trusted
by a trusted entity peer credential source.
o negative BOOLEAN, o negative BOOLEAN,
o mapped BOOLEAN, o mapped BOOLEAN,
o critical BOOLEAN, o critical BOOLEAN,
o values SET OF OCTET STRING, o values SET OF OCTET STRING,
o display_values SET OF STRING o display_values SET OF STRING
skipping to change at page 9, line 34 skipping to change at page 9, line 38
known or set. known or set.
o GSS_S_FAILURE indicates a general error. o GSS_S_FAILURE indicates a general error.
This function outputs the value(s) associated with a given GSS name This function outputs the value(s) associated with a given GSS name
object for a given name attribute. object for a given name attribute.
NOTE: This function relies on the GSS-API notion of "SET OF" allowing NOTE: This function relies on the GSS-API notion of "SET OF" allowing
for order preservation; this has been discussed on the KITTEN WG for order preservation; this has been discussed on the KITTEN WG
mailing list and the consensus seems to be that, indeed, that was mailing list and the consensus seems to be that, indeed, that was
always the intention. always the intention. It should be noted however that the order
presented does not always reflect an underlying order of the
mechanism specific source of the attribute values.
8.1. C-Bindings 8.1. C-Bindings
The C-bindings of GSS_Get_name_attribute() requires one function call The C-bindings of GSS_Get_name_attribute() requires one function call
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
skipping to change at page 10, line 48 skipping to change at page 11, line 10
o GSS_S_COMPLETE indicates no error. o GSS_S_COMPLETE indicates no error.
o GSS_S_UNAVAILABLE indicates that the given attribute OID is not o GSS_S_UNAVAILABLE indicates that the given attribute OID is not
known or could not be set. known or could not be set.
o GSS_S_FAILURE indicates a general error. o GSS_S_FAILURE indicates a general error.
NOTE: This function relies on the GSS-API notion of "SET OF" allowing NOTE: This function relies on the GSS-API notion of "SET OF" allowing
for order preservation; this has been discussed on the KITTEN WG for order preservation; this has been discussed on the KITTEN WG
mailing list and the consensus seems to be that, indeed, that was mailing list and the consensus seems to be that, indeed, that was
always the intention. always the intention. It should be noted that underlying mechanisms
may not respect the given order.
9.1. C-Bindings 9.1. C-Bindings
The C-bindings of GSS_Set_name_attribute() requires one function call The C-bindings of GSS_Set_name_attribute() requires one function call
per-attribute value, for multi-valued name attributes -- each call per-attribute value, for multi-valued name attributes -- each call
adds one value. To replace an attribute's every value delete the adds one value. To replace an attribute's every value delete the
attribute's values first with GSS_Delete_name_attribute(). attribute's values first with GSS_Delete_name_attribute().
OM_uint32 gss_set_name_attribute( OM_uint32 gss_set_name_attribute(
OM_uint32 *minor_status, OM_uint32 *minor_status,
skipping to change at page 11, line 42 skipping to change at page 12, line 5
o minor_status INTEGER o minor_status INTEGER
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_UNAVAILABLE indicates that the given attribute OID is not o GSS_S_UNAVAILABLE indicates that the given attribute OID is not
known. known.
o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was
attempted eg deleting a negative attribute.
o GSS_S_FAILURE indicates a general error. o GSS_S_FAILURE indicates a general error.
Deletion of negative authenticated attributes from NAME objects MUST Deletion of negative authenticated attributes from NAME objects MUST
NOT be allowed. [Do we need a new major status code for "permission NOT be allowed and must result in a GSS_S_UNAUTHORIZED.
denied"?]
10.1. C-Bindings 10.1. C-Bindings
OM_uint32 gss_delete_name_attribute( OM_uint32 gss_delete_name_attribute(
OM_uint32 *minor_status, OM_uint32 *minor_status,
gss_name_t name, gss_name_t name,
gss_OID attr gss_OID attr
); );
11. GSS_Export_name_composite() 11. GSS_Export_name_composite()
Inputs: Inputs:
skipping to change at page 13, line 11 skipping to change at page 13, line 19
gss_name_t name, gss_name_t name,
gss_buffer_t exp_composite_name gss_buffer_t exp_composite_name
); );
12. GSS_Map_name_to_any() 12. GSS_Map_name_to_any()
Inputs: Inputs:
o name NAME, o name NAME,
o authenticated BOOLEAN, -- if TRUE no data will be output unless it o authenticated BOOLEAN, -- if TRUE only authenticated attributes
is authenticated will be included
o type_id OBJECT IDENTIFIER o type_id OBJECT IDENTIFIER
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
o minor_status INTEGER, o minor_status INTEGER,
o output ANY DEFINED BY type_id o output ANY DEFINED BY type_id
skipping to change at page 15, line 40 skipping to change at page 15, line 47
o an optional normative reference to documentation for the given o an optional normative reference to documentation for the given
name attribute name attribute
The allocation and registration policy should be first come, first The allocation and registration policy should be first come, first
served. Registry entries' OIDs need not be based on the base OID served. Registry entries' OIDs need not be based on the base OID
given above. given above.
15. Security Considerations 15. Security Considerations
<TBA> This document extends the GSS-API naming model to include support for
name attributes. The intention is that name attributes are to be
used as a basis for (among other things) authorization decisions or
application personalization for applications relying on GSS-API
security contexts.
[In particular, the status of a name attribute as "authenticated" vs. The security of the application may be critically dependent on the
"asserted" requires close review, particularly with respect to PKIX security of the attributes. This document classifies attributes as
certificate extensions.] asserted or authenticated. Only authenticated attributes MUST be
used if the attribute has security implications for the application
(eg authorization decisions) since asserted attributes may easily be
controlled by the peer directly.
[Also, we need to work out the security considerations of (and It is important to understand the meaning of 'authenticated' in this
possibly remove) negative attributes.] setting. It does not mean that any semantic of the attribute is
claimed to be true. The only implication is that a trusted third
party has asserted the attribute as opposed to the attribute being
asserte by the peer itself. Any additional semantics is always the
result of applying policy. For instance in a given deployment the
mail attribute of the subject may be authenticated and sourced from
an email system where 'correct' values are kept. In another setting
users may be allowed to modify their mail addresses freely. In both
cases the 'mail' attribute may be authenticated by virtue of being
included in signed SAML attribute assertions or by other means
authenticated by the underlying mechanism.
When the underlying security mechanism does not provide a permanent
unique identity (eg anonymous kerberos) the GSS-API naming extensions
may be used to provide a replacement permanent unique identity
attribute which in this case may be unique for each relying party.
This is analogous to the Liberty Alliance targetedID attribute and
has similar security implications.
16. Normative References 16. Normative References
[I-D.GSS-NAMING] [I-D.GSS-NAMING]
Hartman, S., "Desired Enhancements to GSSAPI Naming", Hartman, S., "Desired Enhancements to GSSAPI Naming",
draft-ietf-kitten-gss-naming-01.txt (work in progress), draft-ietf-kitten-gss-naming-01.txt (work in progress),
February 2005. February 2005.
[I-D.ietf-krb-wg-kerberos-clarifications] [I-D.ietf-krb-wg-kerberos-clarifications]
Neuman, C., "The Kerberos Network Authentication Service Neuman, C., "The Kerberos Network Authentication Service
(V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work (V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work
in progress), September 2004. in progress), September 2004.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[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.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
[RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues
and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999.
[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.
[RFC2744] Wray, J., "Generic Security Service API Version 2 : [RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000. C-bindings", RFC 2744, January 2000.
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
Author's Address [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.
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
Intellectual Property Statement Leif Johansson
Stockholm university
Avdelningen foer IT och Media
Stockholm SE-106 91
Email: leifj@it.su.se
URI: http://people.su.se/~leifj/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 18, line 28 skipping to change at line 813
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 45 change blocks. 
94 lines changed or deleted 174 lines changed or added

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