draft-ietf-kitten-gssapi-naming-exts-07.txt   draft-ietf-kitten-gssapi-naming-exts-08.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: November 19, 2010 SUNET Expires: December 26, 2010 SUNET
May 18, 2010 June 24, 2010
GSS-API Naming Extensions GSS-API Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-07.txt draft-ietf-kitten-gssapi-naming-exts-08.txt
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
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 26, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 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
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
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. Attribute Name Syntax . . . . . . . . . . . . . . . . . . 4
6. Mapping Mechanism Facilities to Name Attributes . . . . . 4 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 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 [I-D.GSS-NAMING] the GSS-API's naming architecture As described in [RFC4768] the GSS-API's naming architecture suffers
suffers from certain limitations. This document proposes concrete from certain limitations. This document proposes concrete GSS-API
GSS-API extensions as outlined in [I-D.GSS-NAMING]. extensions.
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.
skipping to change at page 4, line 35 skipping to change at page 4, line 35
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 as described in [RFC3001] MUST be used. 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 If for example the OID 1.2.3 denotes an Extended Key Usage (cf
below), the corresponding GSS-API attribute name MUST be represented below), the corresponding GSS-API attribute name MUST be represented
as urn:oid:1.2.3. 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-
skipping to change at page 14, line 11 skipping to change at page 14, line 11
[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.
[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.
[RFC3001] Mealling, M., "A URN Namespace of Object Identifiers",
RFC 3001, November 2000.
[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 10.2. Informative References
[I-D.GSS-NAMING] [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers",
Hartman, S., "Desired Enhancements to GSSAPI Naming", RFC 3061, February 2001.
draft-ietf-kitten-gss-naming-01.txt (work in progress),
February 2005. [RFC4768] Hartman, S., "Desired Enhancements to Generic Security
Services Application Program Interface (GSS-API) Version 3
Naming", RFC 4768, December 2006.
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. 10 change blocks. 
26 lines changed or deleted 31 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/