draft-ietf-kitten-gssapi-naming-exts-14.txt   draft-ietf-kitten-gssapi-naming-exts-15.txt 
KITTEN WORKING GROUP N. Williams KITTEN WORKING GROUP N. Williams
Internet-Draft Cryptonector, LLC Internet-Draft Cryptonector, LLC
Intended status: Standards Track L. Johansson Intended status: Standards Track L. Johansson
Expires: September 28, 2012 SUNET Expires: December 2, 2012 SUNET
S. Hartman S. Hartman
Painless Security Painless Security
S. Josefsson S. Josefsson
SJD AB SJD AB
March 27, 2012 May 31, 2012
GSS-API Naming Extensions GSS-API Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-14 draft-ietf-kitten-gssapi-naming-exts-15
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 September 28, 2012. This Internet-Draft will expire on December 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
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 . . . . . . . . . . . . 4 1. Conventions used in this document . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3. Name Attribute Authenticity . . . . . . . . . . . . . . . 4 3. Name Attribute Authenticity . . . . . . . . . . . . . . . 5
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() . . . . . . . . . . . . . . . . . . 9 7.3. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 9
7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9
7.4. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 10 7.4. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 10
7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10 7.4.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 4, line 14 skipping to change at page 4, line 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
from certain limitations. This document proposes concrete GSS-API from certain limitations. This document defines concrete GSS-API
extensions. 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.
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 (e.g., an X509 attribute certificate or
SAML attribute assertion), or may have been set on a GSS name for the signed SAML attribute assertion), or may have been set on a GSS name
purpose of locally "asserting" the attribute during credential for the purpose of locally "asserting" the attribute during
acquisition or security context exchange. Name attributes' values credential acquisition or security context exchange. Name
are network representations thereof (e.g., the actual value octets of attributes' values are network representations thereof (e.g., the
the contents of an X.509 certificate extension, for example) and are actual value octets of the contents of an X.509 certificate
intended to be useful for constructing portable access control extension, for example) and are intended to be useful for
facilities. Applications may often require language- or platform- constructing portable access control facilities. Applications may
specific data types, rather than network representations of name often require language- or platform-specific data types, rather than
attributes, so a function is provided to obtain objects of such types network representations of name attributes, so a function is provided
associated with names and name attributes. to obtain objects of such types associated with names and name
attributes.
Future updates of this specification may involve adding an attribute Future updates of this specification may involve adding an attribute
namespace for attributes that only have application-specific namespace for attributes that only have application-specific
semantics. Note that mechanisms will still need to know how to semantics. Note that mechanisms will still need to know how to
transport such attributes. The IETF may also wish to add functions transport such attributes. The IETF may also wish to add functions
by which to inquire whether a mechanism(s) understands a given by which to inquire whether a mechanism(s) understands a given
attribute name or namespace, and to list which attributes or attribute name or namespace, and to list which attributes or
attribute namespaces a mechanism understands. Finally, the IETF may attribute namespaces a mechanism understands. Finally, the IETF may
want to consider adding a function by which to determine the name of want to consider adding a function by which to determine the name of
the issuer of a name attribute. the issuer of a name attribute.
3. Name Attribute Authenticity 3. Name Attribute Authenticity
An attribute is 'authenticated' iff there is a secure association An attribute is 'authenticated' if and only if there is a secure
between the attribute (and its values) and the trusted source of the association between the attribute (and its values) and the trusted
peer credential. Examples of authenticated attributes are (any part source of the peer credential. Examples of authenticated attributes
of) the signed portion of an X.509 certificate or AD-KDCIssued are (any part of) the signed portion of an X.509 certificate or AD-
authorization-data elements in Kerberos V Tickets provided of course KDCIssued authorization-data elements in Kerberos V Tickets provided
that the authenticity of the respective security associations (eg of course that the authenticity of the respective security
signatures) have been verified. associations (e.g., 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 was authorized to assert the attribute. Such credential source was authorized to assert the attribute. Such
interpretations SHOULD 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-authenticated attribute is called _asserted_ in what follows.
follows.This is not to be confused with other uses of the word This is not to be confused with other uses of the word asserted or
asserted or assertion eg "SAML attribute assertion", the attributes assertion such as "SAML attribute assertion", the attributes of which
of which may be authenticated in the sense of this document for may be authenticated in the sense of this document for instance if
instance if the SAML attribute assertion was signed by a key trusted 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. Naming Contexts 5. Naming Contexts
skipping to change at page 6, line 13 skipping to change at page 6, line 12
this case, the set of group memberships or entitlements that the IDP 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 is permitted to make needs to be filtered by the policy of the
acceptor and federation. acceptor and federation.
So even an attribute containing the same information such as e-mail So even an attribute containing the same information such as e-mail
address would need to be treated differently by the application in address would need to be treated differently by the application in
the context of an enterprise deployment from the context of a the context of an enterprise deployment from the context of a
federation. federation.
Another aspect related to trust is the role of the credential issuer Another aspect related to trust is the role of the credential issuer
in providing the attribute. Consider Kerberos PKINIT (RFC 4556). In in providing the attribute. Consider Kerberos PKINIT [RFC4556]. In
this protocol, a public key and associated certificate are used to this protocol, a public key and associated certificate are used to
authenticate to a Kerberos KDC. Consider how attributes related to a authenticate to a Kerberos KDC. Consider how attributes related to a
pkinit certificate should be made available in GSS-API pkinit certificate should be made available in GSS-API
authentications based on the Kerberos ticket. In some deployments authentications based on the Kerberos ticket. In some deployments
the certificate may be fully trusted; in including the certificate 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 ticket, the KDC permits the acceptor to trust the
information in the certificate just as if the KDC itself had made information in the certificate just as if the KDC itself had made
these statements. In other deployments, the KDC may have authorized these statements. In other deployments, the KDC may have authorized
a hash of the certificate without evaluating the content of the a hash of the certificate without evaluating the content of the
certificate or generally trusting the issuing certificate authority. certificate or generally trusting the issuing certification
In this case, if the certificate were included in the issued ticket, authority. In this case, if the certificate were included in the
the KDC would only be making the statement that the certificate was issued ticket, the KDC would only be making the statement that the
used in the authentication. This statement would be authenticated, certificate was used in the authentication. This statement would be
but would not imply that the KDC stated particular attributes of the authenticated, but would not imply that the KDC stated particular
certificate described the initiator. attributes of the certificate described the initiator.
Another aspect of context is encoding of the attribute information. Another aspect of context is encoding of the attribute information.
An attribute containing an ASCII or UTF-8 version of an e-mail An attribute containing an ASCII [ANSI.X3-4.1986] or UTF-8 [RFC3629]
address could not be interpreted the same as a ASN.1 Distinguished version of an e-mail address could not be interpreted the same as a
Encoding Rules e-mail address in a certificate. ASN.1 Distinguished Encoding Rules e-mail address in a certificate.
All of these contextual aspects of a name attribute affect whether All of these contextual aspects of a name attribute affect whether
two attributes can be treated the same by an application and thus two attributes can be treated the same by an application and thus
whether they should be considered the same name attribute. In the whether they should be considered the same name attribute. In the
GSS-API naming extensions, attributes that have different contexts GSS-API naming extensions, attributes that have different contexts
MUST have different names so they can be distinguished by MUST have different names so they can be distinguished by
applications. As an unfortunate consequence of this requirement, applications. As an unfortunate consequence of this requirement,
multiple attribute names will exist for the same basic information. multiple attribute names will exist for the same basic information.
That is, there is no single attribute name for the e-mail address of That is, there is no single attribute name for the e-mail address of
an initiator. Other aspects of how mechanisms describe information an initiator. Other aspects of how mechanisms describe information
about subjects would already make this true. For example, some about subjects would already make this true. For example, some
mechanisms use OIDs to name attributes; others use URIs. mechanisms use OIDs to name attributes; others use URIs.
Local implementations or platforms are likely to have sufficient Local implementations or platforms are likely to have sufficient
policy and information to know when contexts can be treated as the policy and information to know when contexts can be treated as the
same. For example the GSS-API implementation may know that a same. For example the GSS-API implementation may know that a
particular certificate authority can be trusted in the context of a particular certification authority can be trusted in the context of a
pkinit authentication. The local implementation may have sufficient pkinit authentication. The local implementation may have sufficient
policy to know that a particular credential issuer is trusted to make policy to know that a particular credential issuer is trusted to make
a given statement. In order to take advantage of this local a given statement. In order to take advantage of this local
knowledge within the GSS-API implementation, naming extensions knowledge within the GSS-API implementation, naming extensions
support the concept of local attributes in addition to standard support the concept of local attributes in addition to standard
attributes. For example, an implementation might provide a local attributes. For example, an implementation might provide a local
attribute for e-mail address. The implementation would specify the attribute for e-mail address. The implementation would specify the
encoding and representation of this attribute; mechanism-specific encoding and representation of this attribute; mechanism-specific
standards attributes would be re-encoded if necessary to meet this standards attributes would be re-encoded if necessary to meet this
representation. Only e-mail addresses in contexts that meet the representation. Only e-mail addresses in contexts that meet the
skipping to change at page 7, line 27 skipping to change at page 7, line 26
interoperability and usability. Using a local attribute in an interoperability and usability. Using a local attribute in an
application requires knowledge of the local implementation. However application requires knowledge of the local implementation. However
using a standardized attribute in an application requires more using a standardized attribute in an application requires more
knowledge of policy and more validation logic in the application. knowledge of policy and more validation logic in the application.
Sharing this logic in the local platform provides more consistency Sharing this logic in the local platform provides more consistency
across applications as well as reducing implementation costs. Both across applications as well as reducing implementation costs. Both
options are needed. options are needed.
6. Representation of Attribute Names 6. Representation of Attribute Names
Different underlying mechanisms (eg SAML or X.509 certificates) Different underlying mechanisms (e.g., SAML or X.509 certificates)
provide different representations for the names of their attribute. provide different representations for the names of their attribute.
In X.509 certificates, most objects are named by object identifiers In X.509 certificates, most objects are named by object identifiers
(OIDs). The type of object (certificate extension, name constraint, (OIDs). The type of object (certificate extension, name constraint,
keyPurposeID, etc) along with the OID is sufficient to identify the keyPurposeID, etc) along with the OID is sufficient to identify the
attribute. By contrast, according to Section 8.2 and 2.7.3.1 of attribute. By 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. [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 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 part, whose form depends on the format URI, is the actual name. In
other cases an attribute might represent a certificate that plays other cases an attribute might represent a certificate that plays
some particular role in a GSS-API mechanism; such attributes might some particular role in a GSS-API mechanism; such attributes might
skipping to change at page 11, line 19 skipping to change at page 11, line 19
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,
o authenticated BOOLEAN, -- TRUE iff authenticated by the trusted o authenticated BOOLEAN, -- TRUE if and only if authenticated by the
peer credential source. trusted peer credential source.
o complete BOOLEAN -- TRUE iff this represents a complete set of o complete BOOLEAN -- TRUE if and only if this represents a complete
values for the name. set of values for the name.
o values SET OF OCTET STRING -- the caller is responsible for de- o values SET OF OCTET STRING -- the caller is responsible for de-
allocating memory using GSS_Release_buffer_set. allocating memory using GSS_Release_buffer_set.
o display_values SET OF OCTET STRING -- the caller is responsible o display_values SET OF OCTET STRING -- the caller is responsible
for de-allocating memory using GSS_Release_buffer_set for de-allocating memory using GSS_Release_buffer_set
Return major_status codes: Return major_status codes:
o GSS_S_COMPLETE indicates no error. o GSS_S_COMPLETE indicates no error.
skipping to change at page 12, line 21 skipping to change at page 12, line 21
7.5.1. C-Bindings 7.5.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
whose value, on first call to gss_name_attribute_get() MUST be -1, whose value, on first call to gss_get_name_attribute() 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. The status of the complete and authenticated flags initial call. The status of the complete and authenticated flags
MUST NOT change between multiple calls to iterate over values for an MUST NOT change between multiple calls to iterate over values for an
attribute. attribute.
The output buffers "value" and "display_value" are de-allocated by The output buffers "value" and "display_value" are de-allocated by
the caller using gss_release_buffer(). the caller using gss_release_buffer().
skipping to change at page 12, line 49 skipping to change at page 12, line 49
gss_buffer_t display_value, gss_buffer_t display_value,
int *more int *more
); );
7.6. GSS_Set_name_attribute() 7.6. GSS_Set_name_attribute()
Inputs: Inputs:
o name INTERNAL NAME, o name INTERNAL NAME,
o complete BOOLEAN, -- TRUE iff this represents a complete set of o complete BOOLEAN, -- TRUE if and only if this represents a
values for the name. complete set of values for the name.
o attr OCTET STRING, o attr OCTET STRING,
o values SET OF OCTET STRING o values SET OF OCTET STRING
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
o minor_status INTEGER o minor_status INTEGER
skipping to change at page 15, line 9 skipping to change at page 15, line 9
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 NAME 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, such as 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.
7.7.1. C-Bindings 7.7.1. C-Bindings
OM_uint32 gss_delete_name_attribute( OM_uint32 gss_delete_name_attribute(
OM_uint32 *minor_status, OM_uint32 *minor_status,
skipping to change at page 16, line 44 skipping to change at page 16, line 44
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
personalization for applications relying on GSS-API security personalization for applications relying on GSS-API 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. Asserted (non-authenticated) attributes asserted or authenticated. Asserted (non-authenticated) attributes
MUST NOT be used if the attribute has security implications for the MUST NOT be used if the attribute has security implications for the
application (eg authorization decisions) since asserted attributes application (e.g., authorization decisions) since asserted attributes
may easily be 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. Authenticated does not imply that any semantic of the setting. Authenticated does not imply that any semantic of the
attribute is claimed to be true. The only implication is that a attribute is claimed to be true. The only implication is that a
trusted third party has asserted the attribute as opposed to the trusted third party has asserted the attribute as opposed to the
attribute being asserte by the peer itself. Any additional semantics attribute being asserted by the peer itself. Any additional
is always the result of applying policy. For instance in a given semantics are always the result of applying policy. For instance in
deployment the mail attribute of the subject may be authenticated and a given deployment the mail attribute of the subject may be
sourced from an email system where 'authoritive' values are kept. In authenticated and sourced from an email system where 'authoritive'
another situations users may be allowed to modify their mail values are kept. In another situation users may be allowed to modify
addresses freely. In both cases the 'mail' attribute may be their mail addresses freely. In both cases the 'mail' attribute may
authenticated by virtue of being included in signed SAML attribute be 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 (e.g., anonymous kerberos), GSS-API naming extensions unique identity (e.g., anonymous kerberos), GSS-API naming extensions
may be used to provide a permanent unique identity attribute. This may be used to provide a permanent unique identity attribute. This
may be a globally unique identifier, a value unique within the may be a globally unique identifier, a value unique within the
namespace of the attribute issuer, or a "directed" identifier that is namespace of the attribute issuer, or a "directed" identifier that is
unique per peer acceptor identity. SAML, to use one example unique per peer acceptor identity. SAML, to use one example
technology, offers a number of built-in constructs for this purpose, technology, offers a number of built-in constructs for this purpose,
skipping to change at page 17, line 50 skipping to change at page 17, line 50
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.
[RFC5587] Williams, N., "Extended Generic Security Service Mechanism [RFC5587] Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", RFC 5587, July 2009. Inquiry APIs", RFC 5587, July 2009.
10.2. Informative References 10.2. Informative References
[ANSI.X3-4.1986]
American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[OASIS.saml-bindings-2.0-os]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Maler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS
Standard saml-bindings-2.0-os, March 2005.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005. 2.0-os, March 2005.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[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
Cryptonector, LLC Cryptonector, LLC
Email: nico@cryptonector.com Email: nico@cryptonector.com
 End of changes. 23 change blocks. 
58 lines changed or deleted 75 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/