One document matched: draft-ietf-abfab-gss-eap-naming-04.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2743 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY SAML2Core SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml">
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>    <!ENTITY gss-eap PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-abfab-gss-eap.xml'>
    <!ENTITY gss-naming PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-kitten-gssapi-naming-exts.xml'>

]>

<rfc category="std" ipr="trust200902" docName="draft-ietf-abfab-gss-eap-naming-04">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

  <front>
    <title abbrev="GSS EAP Name Attributes">Name Attributes for the GSS-API EAP mechanism</title>
        <author initials="S." surname="Hartman" fullname="Sam Hartman" >
      <organization>Painless Security</organization>
      <address>
	<email>hartmans-ietf@mit.edu</email>
      </address>
    </author>    <author initials="J." surname="Howlett" fullname="Josh Howlett">
      <organization>JANET(UK)</organization>
      <address>
	<email>josh.howlett@ja.net</email>
      </address>
    </author>


    <date/>
    <abstract>
      <t>The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information.</t>
    </abstract>
  </front>

    <middle>
    <section title="Introduction">
      <t>The naming extensions <xref
      target="I-D.ietf-kitten-gssapi-naming-exts"/>to the Generic Security Services
      Application Programming interface (GSS-API) <xref target="RFC2743"/> provide a mechanism for
      applications to discover authorization and personalization
      information associated with GSS-API names. The Extensible
      Authentication Protocol GSS-API mechanism <xref
      target="I-D.ietf-abfab-gss-eap"/> allows an
      Authentication/Authorization/Accounting peer to provide
      authorization attributes along side an authentication
      response. It also provides mechanisms to process Security
      Assertion Markup Language (SAML) messages provided in the AAA
      response. Other mechanisms such as SAML EC <xref target="I-D.ietf-kitten-sasl-saml-ec"/> also support SAML assertions and attributes carried in the GSS-API. This document describes the necessary information to
      use the naming extensions API to access SAML assertions in the federated context and AAA attributes.</t> 
      <t>The semantics of setting attributes defined in this specification are undefined and left to future work.</t>
    </section>
        <section title="Requirements notation">
            <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
            "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
            and "OPTIONAL" in this document are to be interpreted as
            described in <xref target="RFC2119"/>.</t>
        </section>
    <section title="Naming Extensions and SAML">
      <t>SAML assertions can carry attributes describing properties of
      the subject of the assertion. For example, an assertion might
      carry an attribute describing the organizational affiliation or
      e-mail address of a subject. According to Section 8.2 and
      2.7.3.1 of <xref target="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. GSS-API name attributes may take a form starting with a URI describing the form of the name; the rest of the name is specified by that URI. </t>
      <t>SAML attributes carried in GSS-API names are named with three parts. The first is a URN indicating that the name is a SAML attribute and describing the context (<xref target="FED.CONTEXT"/>). This URN is followed by a space, the  URI indicating the format of the SAML name, a space and the SAML attribute name. The URI indicating the format of the SAML attribute name is not optional and MUST be present.</t>
      <t>SAML attribute names may not be globally unique. Many names that are named by URNs or URIs are likely to have semantics independent of the issuer. However other name formats, including unspecified name formats, make it easy for two issuers to choose the same name for attributes with different semantics. Attributes using  the federated context <xref target="FED.CONTEXT"/> are issued by the same party performing the authentication. So, based on who is the subject  of the name, the semantics of the attribute can be determined.</t>
    </section>
    <section anchor="FED.CONTEXT" title="Federated Context">
      <t>GSS-API naming extensions have the concept of an
      authenticated name attribute. The mechanism guarantees that the
      contents of an authenticated name attribute are an authenticated
      statement from the trusted source of the peer credential. The fact
      that an attribute is authenticated does not imply that the
      trusted source of the peer credential is authorized to assert
      the attribute.</t>
      <t>In the federated context, the trusted source of the peer
      credential is typically some identity provider. In the GSS EAP
      mechanism, information is combined from AAA and SAML
      sources. The SAML IDP and home AAA server are assumed to be in
      the same trust domain. However, this trust domain is not
      typically the same as the trust domain of the service. With other SAML mechanisms using this specification, the SAML assertion also comes from the party performing authentication. Typically, the IDP is run by another organization in the same federation. The IDP is trusted to make some statements, particularly related to the context of a federation. For example, an academic federation's participants would typically trust an IDP's assertions about whether someone was a student or a professor. However that same IDP would not typically be trusted to make assertions about local entitlements such as group membership. Thus, a
      service MUST make a policy decision about whether the IDP is
      permitted to assert a particular attribute and about whether the
      asserted value is acceptable.</t>
      <t>In contrast, attributes in an enterprise context are often
      verified by a central authentication infrastructure that is
      trusted to assert most or all attributes. For example, in a Kerberos infrastructure, the KDC typically indicates group membership information for clients to a server using KDC-authenticated authorization data.</t>
<t>The context of an attribute is an important property of that
      attribute; trust context is an important part of this overall 
      context. In order for applications to distinguish the context of
      attributes, attributes with different context need different
      names.  This specification defines attribute names for SAML and AAA attributes in the federated context. </t>
      <t>These names MUST NOT be used for attributes issued by a party other than one closely associated with the source of credentials unless the source of credentials is re-asserting the attributes. For example, a source of credentials can consult whatever sources of attributes it chooses, but acceptors can assume attributes in the federated context are from the source of credentials.</t>
    </section>
    <section anchor="RADIUS" title="Name Attributes for GSS-EAP">
      <t>This section describes how RADIUS attributes received in an access-accept message by  the GSS-EAP <xref target="I-D.ietf-abfab-gss-eap"/> mechanism are named. The use of attributes defined in this section for other RADIUS messages or prior to the access-accept message is undefined at this time. Future specifations can explore these areas giving adequate weight to backward compatibility.</t>
      <t>The first portion of the name is urn:ietf:params:gss:radius-attribute (a URN indicating that this is a GSS-EAP RADIUS AVP). This is followed by a space and a numeric RADIUS name as described by section 2.6 of <xref target="I-D.ietf-radext-radius-extensions"/>. For example the name of the User-Name attribute is "urn:ietf:gss:radius-attribute 1". The name of extended type 1 within type 241 would be "urn:ietf:gss:radius-attribute 241.1".</t>
      <t>The value of RADIUS attributes is the raw octets of the packet. Integers are in network byte order. The display value SHOULD be a human readable string; an implementation can only produce this string if it knows the type of a given RADIUS attribute. If multiple attributes are present with a given name in the RADIUS message, then a multi-valued GSS-API attribute SHOULD be returned. As an exception, implementations SHOULD concatenate RADIUS attributes such as EAP-Message or large attributes defined in <xref target="I-D.ietf-radext-radius-extensions"></xref> that use multiple attributes to carry more than 253 octets of information.</t>
    </section>
    <section title="Names of SAML Attributes in the Federated Context">
      <section anchor="ASSERTION" title="Assertions">
	<t>An assertion generated by the credential source is named by "urn:ietf:params:gss:federated-saml-assertion". The
	value of this attribute is the assertion carried in the AAA
	protocol or used for authentication in a SAML mechanism. This attribute is absent from a given acceptor name
	if no such assertion is present or if the assertion fails
	local policy checks. This attribute is always
	authenticated when present in mechanism names for mechanisms complying with this specification: authentication only succeeds if the
	SAML or AAA  exchange is successfully authenticated. However, users of
	the GSS-API MUST confirm that the attribute is authenticated
	because some other mechanisms MAY permit an initiator to assert an
	unauthenticated version of this attribute.</t> 
      </section>
      <section anchor="SAML-ATTRIBUTE" title="SAML Attributes">
	<t>Each attribute carried in the assertion SHOULD also be a
	GSS name attribute. The name of this attribute has three
	parts, all separated by an ASCII space character. The first
	part is urn:ietf:params:gss:federated-saml-attribute. The second part is the
URI for the <saml:Attribute> element's NameFormat XML attribute.  The
final part is the <saml:Attribute> element's Name XML attribute. </t>
	<t>If the content of each <saml:AttributeValue> element is a simple text node
(or nodes), then the raw and "display" values of the GSS name attribute
MUST be the text content of the element(s). The raw value MUST be encoded as UTF-8.</t>
	<t>If the value is not simple or is empty, then the raw value(s) of the GSS name
attribute MUST be the well-formed serialization of the
<saml:AttributeValue> element(s) encoded as UTF-8. The "display" values
are implementation-defined.</t>
	<t>These attributes SHOULD be marked authenticated if they are
	contained in SAML assertions that have been successfully
	validated back to the trusted source of the peer
	credential. In the GSS-EAP mechanism, a SAML assertion carried
	in an integrity-protected and authenticated AAA protocol SHALL
	be sufficiently validated. An implementation MAY apply local
	policy checks to this assertion and discard it if it is
	unacceptable according to these checks.</t>
      </section>
      <section anchor="NAMEID" title="SAML Name Identifiers">
	<t >The <saml:NameID> carried in the subject of the assertion SHOULD also be a
GSS name attribute. The name of this attribute has two parts, separated by
an ASCII space character. The first part is urn:ietf:params:gss:federated-saml-nameid. The second part is the
URI for the <saml:NameID> element's Format XML attribute.</t>
	<t>The raw value of the GSS name attribute MUST be the well-formed
serialization of the <saml:NameID> element encoded as UTF-8. The "display"
value is implementation-defined. For formats defined by section 8.3 of
<xref target="OASIS.saml-core-2.0-os" />, missing values of the NameQualifier or SPNameQualifier XML
attributes MUST be populated in accordance with the definition of the
format prior to serialization. In other words, the defaulting rules
specified for the "persistent" and "transient" formats MUST be applied
prior to serialization.</t>
	<t>This attribute SHOULD be marked authenticated if the name identifier is
contained in a SAML assertion that has been successfully validated back to
the trusted source of the peer credential.  In the GSS-EAP mechanism, a
SAML assertion carried in an integrity-protected and authenticated AAA
protocol SHALL be sufficiently validated.  An implementation MAY apply
local policy checks to this assertion and discard it if it is unacceptable
according to these checks.
</t>
      </section>
    </section>
        <section title="Security Considerations">
      <t>This document describes how to access RADIUS attributes, SAML attributes and SAML assertions from some GSS-API mechanisms. These attributes are typically used for one of two purposes. The least sensitive is personalization: a central service MAY provide information about an authenticated user so they need not enter it with each acceptor they access. A more sensitive use is authorization.</t>
      <t>The mechanism is responsible for authentication and integrity protection of the attributes. However, the acceptor application is responsible for making a decision about whether the credential source is trusted to assert the attribute and validating the asserted value. </t>
      <t>mechanisms are permitted to perform local policy checks on SAML assertions, attributes and name identifiers exposed through name attributes defined in this document. If there is another way to get access to the SAML assertion, for example the mechanism described in <xref target="I-D.ietf-abfab-aaa-saml"/>, then an application MAY get different results depending on how the SAML is accessed. This is intended behavior; applications who choose to bypass local policy checks SHOULD perform their own evaluation before relying on information.</t>
        </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>A new top-level registry is created titled "Generic Security Service Application Program Interface Parameters". There doesn't seem to be an existing top-level registry that can be used. There are Parameters for the Kerberos V mechanism; parameters for the GSS-API EAP mechanism; and GSS-API/SASL/Kerberos service names. However none of these are the right place.</t>
      <t>In this top-level registry, a sub-registry titled "GSS-API URN Parameters" is created. Registration in this registry is by the IETF review or expert review procedures <xref target="RFC5226"/>. Registrations in this registry are generally only expected as part of protocols published as RFCs on the IETF stream; other URIs are expected to be better choices for non-IETf work. Expert review is permitted mainly to permit early registration related to specifications under development when the community believes they have reach sufficient maturity.</t>
      <t>If the "paramname" parameter is registered in this registry then its URN will be "urn:ietf:gss:paramname". The initial registrations are as follows:</t>
      <texttable>
	<ttcol>Parameter</ttcol> <ttcol>Reference</ttcol>
	<c>radius-attribute</c> <c><xref target="RADIUS"></xref></c>
	<c>federated-saml-assertion</c> <c><xref target="ASSERTION"></xref></c>
	<c>federated-saml-attribute</c> <c><xref target="SAML-ATTRIBUTE"></xref></c>
	<c>federated-saml-nameid</c> <c><xref target="NAMEID"></xref></c>

      </texttable>
      <section title="Registration of the GSS URN Namespace">
	<t>IANA is requested to register the "gss" URN sub-namespace in the IETF URN sub-namespace for protocol parameters defined in <xref target="RFC3553"></xref>.</t>
	<t>Registry Name: gss</t>
	<t>Specification: draft-ietf-abfab-gss-eap-naming</t>
	<t>Repository: GSS-API URN Parameters (<xref target="IANA"></xref>)</t>

	<t>Index Value: Sub-parameters MUST be specified in UTF-8 using standard URI encoding where necessary.</t>
      </section>
    </section>
    <section title="Acknowledgements">
      <t>Scott Cantor contributed significant text and multiple reviews of this document.</t>
      <t>Sam hartman's work on this specification has been funded by Janet.</t>
    </section>
    </middle>

    <back>
        <references title='Normative References'>&rfc2119;
    &gss-eap;
&gss-naming;
      &rfc2743;
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-radext-radius-extensions'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3553'?>
&SAML2Core;
</references>
    <references title="Informative References">
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-kitten-sasl-saml-ec'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-abfab-aaa-saml'?>

    </references>
    </back>

</rfc>