draft-ietf-kitten-gssapi-naming-exts-08.txt   draft-ietf-kitten-gssapi-naming-exts-09.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: December 26, 2010 SUNET Expires: August 10, 2011 SUNET
June 24, 2010 February 6, 2011
GSS-API Naming Extensions GSS-API Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-08.txt draft-ietf-kitten-gssapi-naming-exts-09
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 model to support introduces new APIs that extend the GSS-API naming model to support
name attribute transfer between GSS-API peers. name attribute transfer between GSS-API peers.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on December 26, 2010. This Internet-Draft will expire on August 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 23 skipping to change at page 2, line 23
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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. Naming Contexts . . . . . . . . . . . . . . . . . . . . . 4
6. Mapping Mechanism Facilities to Name Attributes . . . . . 4 6. Representation of Attribute Names . . . . . . . . . . . . 6
6.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 5 7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 7
6.2.1. Standard PKIX Certificate Extensions . . . . . . . . . . . 5 7.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.2. Other PKIX Certificate Extensions and Attributes . . . . . 5 7.2. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 8
6.3. SAML attribute assertions . . . . . . . . . . . . . . . . 6 7.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8
7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.3. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 9
7.1. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6 7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 7.4. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 10
7.2. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7 7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 7.5. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 12
7.3. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8 7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 7.6. GSS_Export_name_composite() . . . . . . . . . . . . . . . 12
7.4. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 9 7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13
7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 13
7.5. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . 13
7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . 14
7.6. GSS_Export_name_composite() . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14
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 [RFC4768] the GSS-API's naming architecture suffers As described in [RFC4768] the GSS-API's naming architecture suffers
skipping to change at page 4, line 22 skipping to change at page 4, line 22
instance if the SAML attribute assertion was signed by a key trusted instance if the SAML attribute assertion was signed by a key trusted
by the peer. by the peer.
4. Name Attributes/Values as ACL Subjects 4. Name Attributes/Values as ACL Subjects
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.
5. Attribute Name Syntax 5. Naming Contexts
Attribute names are represented as opaque STRING elements in the API
described below. These attribute names have syntax and semantics
that are understood by the application and by the lower-layer
implementations (some of which are described below). In order to
present a consistent namespace to the application and at the same
time impose as few transformation requirements as possible to lower-
layer implementations attribute names SHOULD be URIs.
Technologies used in lower-layer protocols may of course use
attribute naming that are not based on URIs. Notably X.509
certificates will use OIDs for most naming purposes. In this case
OIDs MUST be mapped into URIs as described in [RFC3061] MUST be used.
If for example the OID 1.2.3 denotes an Extended Key Usage (cf
below), the corresponding GSS-API attribute name MUST be represented
as urn:oid:1.2.3.
6. Mapping Mechanism Facilities to Name Attributes Several factors influence the context in which a name attribute is
interpreted. One is the trust context.
In this section we describe two important examples of lower-layer As discussed previously, applications apply local policy to determine
implementations of this API. These examples are not mandatory to whether a particular peer credential issuer is trusted to make a
implement and are only provided for reference. The use of [RFC2119]- given statement. Different GSS-API mechanisms and deployments have
terms in this section is limited to those implementations of the GSS- different trust models surrounding attributes they provide about a
API naming extensions that choose to implement these lower-layer name.
technologies. Future mappings SHOULD be documented as RFCs.
Kerberos V [RFC4120] and the Simple Public-Key GSS-API Mechanism, For example, Kerberos deployments in the enterprise typically trust a
SPKM described in [RFC2025], both support the concept and encoding of KDC to make any statement about principals in a realm. This includes
containers of "authorization-data" as described in [RFC4120]. attributes such as group membership.
PKIX [RFC5280] supports a number of attribute-like features, like In contrast, in a federated SAML environment, the identity provider
Extended Key Usage values (EKUs) and certificate extensions. typically exists in a different organization than the acceptor. In
this case, the set of group memberships or entitlements that the IDP
is permitted to make needs to be filtered by the policy of the
acceptor and federation.
6.1. Kerberos V and SPKM Authorization-Data So even an attribute containing the same information such as e-mail
address would need to be treated differently by the application in
the context of an enterprise deployment from the context of a
federation.
Authorization-data non-container elements asserted in Kerberos V AP- Another aspect related to trust is the role of the credential issuer
REQ Authenticators MUST be mapped into *asserted* GSS-API name in providing the attribute. Consider Kerberos PKINIT (RFC 4556). In
attributes. this protocol, a public key and associated certificate are used to
authenticate to a Kerberos KDC. Consider how attributes related to a
pkinit certificate should be made available in GSS-API
authentications based on the Kerberos ticket. In some deployments
the certificate may be fully trusted; in including the certificate
information in the ticket, the KDC permits the acceptor to trust the
information in the certificate just as if the KDC itself had made
these statements. In other deployments, the KDC may have authorized
a hash of the certificate without evaluating the content of the
certificate or generally trusting the issuing certificate authority.
In this case, if the certificate were included in the issued ticket,
the KDC would only be making the statement that the certificate was
used in the authentication. This statement would be authenticated,
but would not imply that the KDC stated particular attributes of the
certificate described the initiator.
Authorization-data included in Kerberos V Tickets that is not Another aspect of context is encoding of the attribute information.
contained in AD-KDCIssued (with valid signature) MUST be mapped into An attribute containing an ASCII or UTF-8 version of an e-mail
*asserted* GSS-API name attributes. Conversely, authorization-data address could not be interpreted the same as a ASN.1 Distinguished
elements in Kerberos V Tickets contained by AD-KDCIssued MUST be Encoding Rules e-mail address in a certificate.
mapped into *authenticated* GSS-API name attributes.
6.2. PKIX All of these contextual aspects of a name attribute affect whether
two attributes can be treated the same by an application and thus
whether they should be considered the same name attribute. In the
GSS-API naming extensions, attributes that have different contexts
MUST have different names so they can be distinguished by
applications. As an unfortunate consequence of this requirement,
multiple attribute names will exist for the same basic information.
That is, there is no single attribute name for the e-mail address of
an initiator. Other aspects of how mechanisms describe information
about subjects would already make this true. For example, some
mechanisms use OIDs to name attributes; others use URIs.
6.2.1. Standard PKIX Certificate Extensions Local implementations or platforms are likely to have sufficient
policy and information to know when contexts can be treated as the
same. For example the GSS-API implementation may know that a
particular certificate authority can be trusted in the context of a
pkinit authentication. The local implementation may have sufficient
policy to know that a particular credential issuer is trusted to make
a given statement. In order to take advantage of this local
knowledge within the GSS-API implementation, naming extensions
support the concept of local attributes in addition to standard
attributes. For example, an implementation might provide a local
attribute for e-mail address. The implementation would specify the
encoding and representation of this attribute; mechanism-specific
standards attributes would be re-encoded if necessary to meet this
representation. Only e-mail addresses in contexts that meet the
requirements of local policy would be mapped into this local
attribute.
PKIX certificate extensions MAY/SHOULD/MUST (see comment above) be Such local attributes inherently expose a tradeoff between
represented as *authenticated* GSS-API name attributes named using interoperability and usability. Using a local attribute in an
the _same_ OID mapped to a URN. application requires knowledge of the local implementation. However
using a standardized attribute in an application requires more
knowledge of policy and more validation logic in the application.
Sharing this logic in the local platform provides more consistency
across applications as well as reducing implementation costs. Both
options are needed.
SubjectAltNames and Extended Key Usage OIDs, specifically, MUST be 6. Representation of Attribute Names
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).
The value associated with Extended Key Usage attributes MUST have
NULL value represented as a zero-length OCTET STRING.
The standard PKIX certificate key usage (KUs, but not EKUs), MUST NOT Different underlying mechanisms provide different representations for
be represented as GSS-API name attributes. the names of their attribute. In X.509 certificates, most objects
are named by object identifiers (OIDs). The type of object
(certificate extension, name constraint, keyPurposeID, etc) along
with the OID is sufficient to identify the attribute. In contrast,
according to Section 8.2 and 2.7.3.1 of [OASIS.saml-core-2.0-os], the
name of an attribute has two parts. The first is a URI describing
the format of the name. The second part, whose form depends on the
format URI, is the actual name. In other cases an attribute might
represent a certificate that plays some particular role in a GSS-API
mechanism; such attributes might have a simple mechanism-defined
name.
PKIX certificate subjectAltNames MUST be mapped as *authenticated* Attribute names MUST support multiple components. If there are more
GSS-API name attributes. The values SHOULD be the values of the than one component in an attribute name, the more significant
subjectAltName represented as OCTET STRINGs if the type of the components define the semantics of the less significant components.
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 Attribute names are represented as STRING elements in the API
described below. These attribute names have syntax and semantics
that are understood by the application and by the lower-layer
implementations (some of which are described below).
Any X.509 certificate extension not covered above SHOULD be If an attribute name contains a space (ASCII 0x20), the first space
represented as GSS-API name attributes with the OID of the X.509 separates the most significant or primary component of the name from
extension and with OCTET STRING values containing the encoded value the remainder. If there is no space, the primary component is the
of the extension. entire name, otherwise it defines the interpretation of the remainder
of the name.s
6.3. SAML attribute assertions If the primary component contains an ASCII : (0x3a), then the primary
component is a URI. Otherwise, the attribute is a local attribute
and the primary component has meaning to the implementation of GSS-
API or to the specific configuration of the application. At this
time, local attribute names are not standardized; there is debate
about whether such standardization will be useful. Any future
standardizations will need to balance potential problems resulting
from attribute names used before standardization.
Attributes contained in SAML attribute assertions MUST be mapped to A sufficient prefix of attribute names needs to be dictated by a
GSS-API name attributes with the same URIs as used in the SAML mechanism in order to describe the context. For example it would be
attribute name. problematic to represent SAML attribute names as the name format URI,
a space, and the remainder of the name. A carefully crafted SAML
assertion could appear to be a name from another mechanism or
context. Typically a SAML attribute name would include a prefix
describing the trust model and other context of the attribute name.
SAML attributes found in SAML attribute assertions MUST NOT be mapped Local attribute names under the control of an administrator or a
as authenticated unless the SAML attribute assertion was signed by a sufficiently trusted part of the platform need not have a prefix to
key trusted by the peer or otherwise protected from unauthorized describe context.
modification.
7. API 7. API
7.1. GSS_Display_name_ext() 7.1. 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
skipping to change at page 14, line 22 skipping to change at page 15, line 22
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 10.2. Informative References
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005.
[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers",
RFC 3061, February 2001. RFC 3061, February 2001.
[RFC4768] Hartman, S., "Desired Enhancements to Generic Security [RFC4768] Hartman, S., "Desired Enhancements to Generic Security
Services Application Program Interface (GSS-API) Version 3 Services Application Program Interface (GSS-API) Version 3
Naming", RFC 4768, December 2006. Naming", RFC 4768, December 2006.
Authors' Addresses Authors' Addresses
Nicolas Williams Nicolas Williams
 End of changes. 25 change blocks. 
102 lines changed or deleted 151 lines changed or added

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