draft-ietf-kitten-gssapi-naming-exts-11.txt   draft-ietf-kitten-gssapi-naming-exts-12.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 25, 2011 SUNET Expires: June 19, 2012 SUNET
S. Hartman S. Hartman
Painless Security Painless Security
S. Josefsson S. Josefsson
SJD AB SJD AB
May 24, 2011 December 17, 2011
GSS-API Naming Extensions GSS-API Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-11 draft-ietf-kitten-gssapi-naming-exts-12
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 38 skipping to change at page 1, line 38
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 November 25, 2011. This Internet-Draft will expire on June 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Conventions used in this document . . . . . . . . . . . . 4 1. Conventions used in this document . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3. Name Attribute Authenticity . . . . . . . . . . . . . . . 4 3. Name Attribute Authenticity . . . . . . . . . . . . . . . 4
4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 5 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 5
5. Naming Contexts . . . . . . . . . . . . . . . . . . . . . 5 5. Naming Contexts . . . . . . . . . . . . . . . . . . . . . 5
6. Representation of Attribute Names . . . . . . . . . . . . 7 6. Representation of Attribute Names . . . . . . . . . . . . 7
7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. SET OF OCTET STRING . . . . . . . . . . . . . . . . . . . 8 7.1. SET OF OCTET STRING . . . . . . . . . . . . . . . . . . . 8
7.2. Const types . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. Const types . . . . . . . . . . . . . . . . . . . . . . . 8
7.3. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 8 7.3. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 9
7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9
7.4. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 9 7.4. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 10
7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10 7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10
7.5. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 10 7.5. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 11
7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 7.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
7.6. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 12 7.6. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 12
7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 7.6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14
7.7. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 13 7.7. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 14
7.7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14 7.7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15
7.8. GSS_Export_name_composite() . . . . . . . . . . . . . . . 14 7.8. GSS_Export_name_composite() . . . . . . . . . . . . . . . 15
7.8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15 7.8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
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 39 skipping to change at page 4, line 39
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
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 Authenticity Future updates of this specification may involve adding an attribute
namespace for attributes that only have application-specific
semantics. Note that mechanisms will still need to know how to
transport such attributes. The IETF may also wish to add functions
by which to inquire whether a mechanism(s) understands a given
attribute name or namespace, and to list which attributes or
attribute namespaces a mechanism understands. Finally, the IETF may
want to consider adding a function by which to determine the name of
the issuer of a name attribute.
3. Name Attribute Authenticity
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
skipping to change at page 13, line 13 skipping to change at page 13, line 21
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
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 NAME 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.
When the given NAME object is an MN this function MUST fail (with
GSS_S_FAILURE) if the mechanism for which the name is an MN does not
recognize the attribute name or the namespace it belomgs to. This is
because name attributes generally have some semantics that mechanisms
must understand.
On the other hand, when the given name is not an MN this function MAY
succeed even if none of the available mechanisms understand the given
attribute, in which subsequent credential acquisition attempts (via
GSS_Acquire_cred() or GSS_Add_cred()) with the resulting name MUST
fail for mechanisms that do not understand any one or more name
attributes set with this function. Applications may wish to use a
non-MN, then acquire a credential with that name as the desired name.
The acquired credentials will have elements only for the mechanisms
that can carry the name attributes set on the name.
Note that this means that all name attributes are locally critical:
the mechanism(s) must understand them. The reason for this is that
name attributes must necessarily have some meaning that the mechanism
must understand, even in the case of application-specific attributes
(in which case the mechanism must know to transport the attribute to
any peer). However, there is no provision to ensure that peers
understand any given name attribute. Individual name attributes may
be critical with respect to peers, and the specification of the
attribute will have to indicate which of the mechanism's protocol or
the application is expected to enforce criticality.
The complete flag denotes that (if TRUE) the set of values represents The complete flag denotes that (if TRUE) the set of values represents
a complete set of values for this name. The peer being an a complete set of values for this name. The peer being an
authoritative source of information for this attribute is a authoritative source of information for this attribute is a
sufficient condition for the complete flag to be set by the peer. sufficient condition for the complete flag to be set by the peer.
In the federated case when several peers may hold some of the In the federated case when several peers may hold some of the
attributes about a name this flag may be highly dangerous and SHOULD attributes about a name this flag may be highly dangerous and SHOULD
NOT be used. NOT be used.
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
skipping to change at page 14, line 14 skipping to change at page 15, line 4
o name INTERNAL NAME, o name INTERNAL NAME,
o attr OCTET STRING, o attr OCTET STRING,
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
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 NAME is not
known. known.
o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was o GSS_S_UNAUTHORIZED indicates that a forbidden delete operation was
attempted eg deleting a negative attribute. 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 and must result in a GSS_S_UNAUTHORIZED. NOT be allowed and must result in a GSS_S_UNAUTHORIZED.
skipping to change at page 16, line 29 skipping to change at page 17, line 18
is always the result of applying policy. For instance in a given is always the result of applying policy. For instance in a given
deployment the mail attribute of the subject may be authenticated and deployment the mail attribute of the subject may be authenticated and
sourced from an email system where 'authoritive' values are kept. In sourced from an email system where 'authoritive' values are kept. In
another situations users may be allowed to modify their mail another situations users may be allowed to modify their mail
addresses freely. In both cases the 'mail' attribute may be addresses freely. In both cases the 'mail' attribute may be
authenticated by virtue of being included in signed SAML attribute authenticated by virtue of being included in signed SAML attribute
assertions or by other means authenticated by the underlying assertions or by other means authenticated by the underlying
mechanism. 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 (e.g., anonymous kerberos), GSS-API naming extensions
may be used to provide a replacement permanent unique identity may be used to provide a permanent unique identity attribute. This
attribute which in this case may be unique for each peer party. This may be a globally unique identifier, a value unique within the
is analogous to the SAML permanentIdentifier attribute and has namespace of the attribute issuer, or a "directed" identifier that is
comparable security and privacy properties and implications. unique per peer acceptor identity. SAML, to use one example
technology, offers a number of built-in constructs for this purpose,
such as a <NameID> with a Format of
"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent". SAML
deployments also typically make use of domain-specific attribute
types that can serve as identifiers.
10. References 10. References
10.1. Normative References 10.1. Normative References
[GFD.024] Argonne National Laboratory, National Center for [GFD.024] Argonne National Laboratory, National Center for
Supercomputing Applications, Argonne National Laboratory, Supercomputing Applications, Argonne National Laboratory,
and Argonne National Laboratory, "GSS-API Extensions", and Argonne National Laboratory, "GSS-API Extensions",
GFD GFD.024, June 2004. GFD GFD.024, June 2004.
 End of changes. 15 change blocks. 
27 lines changed or deleted 67 lines changed or added

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