<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN" "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2307 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2307.xml">
<!ENTITY RFC3961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml">
<!ENTITY RFC3962 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3962.xml">
<!ENTITY RFC3713 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3713.xml">
<!ENTITY RFC4120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY RFC1510 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1510.xml">
<!ENTITY RFC4559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC2898 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2898.xml">
<!ENTITY RFC4493 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4493.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-krb-wg-pad-01"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title>POSIX Authorization Data</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Simo Sorce" initials="S.S." role="editor"
            surname="Sorce">
      <organization>Red Hat</organization>

      <address>
        <email>ssorce@redhat.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Tom Yu" initials="T.Y." role="editor" surname="Yu">
      <organization>MIT Kerberos Consortium</organization>

      <address>
        <email>tlyu@mit.edu</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Thomas Hardjono" initials="T.H." role="editor"
            surname="Hardjono">
      <organization>MIT Kerberos Consortium</organization>

      <address>
        <email>hardjono@mit.edu</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date day="9" month="Feb" year="2012" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Network Working Group</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>Kerberos</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>
	This document proposes a Kerberos Authorization Data element
	containing user and group directory information similar to
	that provided by RFC 2307, typically used by POSIX and
	POSIX-like systems in the course of login type activities.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>There is an increasing need today for Kerberos to support the
      delivery and processing of authorization information pertaining to the
      principals seeking access to the servers. Kerberos today is used
      extensively for authentication to directory services within the
      Enterprise. In many cases, a directory service is implemented as a
      distributed database system organized across multiple realms. As such,
      when a client in one realm seeks access to a directory service component
      located within a different realm, information regarding both the
      identity of the client and the permissions associated with that client
      must be communicated across the realms. Currently there does not exist a
      common and standardized structure in Kerberos (V5) for conveying access
      control or authorization information.</t>

      <t>This draft proposes an authorization data element for Kerberos that
      contains information that is useful for dynamically updating the user
      and group directory information in a POSIX system, usually in the
      course of a login type activity.</t>
    </section>

    <section title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </section>

    <section title="Use-Case: Cross-Realm Directory Services">
      <t>In this section we discuss one of the primary use-case scenarios for
      the POSIX Authorization Data (PAD) structure within Kerberos V5. In
      this use-case a client principal is seeking to access a service in a
      different realm. Since the remote service does not have authorization
      information regarding the client, it needs to obtain it either from
      querying the directory service in its own realm or the directory service
      located in the client's realm. It is here that a common PAD structure
      becomes necessary and invaluable in order to achieve a high-degree of
      interoperability between directory services in distinct realms.</t>

      <t>In this use-case a client principal C1 in realm R1 is seeking access
      to services (or servers) located in a different realm R2. In accessing
      local service S1 in realm R1 the client must first be authenticated by
      KDC1 in that realm. A directory service (e.g. LDAP) called D1 is used in
      realm R1 to perform authorization of the client, after the client has
      been authenticated by KDC1.</t>

      <t>When the client prinicipal later seeks to access services or
      resources S2 in realm R2, following the usual Kerberos flow the client
      must first obtain a cross-realm TGT from KDC1 (in realm R1) and then
      present it to KDC2 (in realm R2) in order to obtain a service-ticket for
      S2. However, one immediate issue is the fact that service S2 does not
      have authorization information regarding the permissions or privileges
      of client C1 in realm R1. The service S2 could query its own directory
      service D2 to obtain authorization information pertaining to client C1.
      In the absence of such information in D2, the service S2 could then
      perform a cross-realm query to the directory services D1 operating in
      realm R1.</t>

      <t>However, this cross-realm query from S2 to D1 is not only
      inefficient, but it also implies knowledge of multiple heterogenous
      systems by all actors. Two different realms may rely on completely
      different infrastructures for user information storage, ranging from
      different LDAP implementations with different schema conventions to NIS,
      SQL databases, flat files, and so on. Every service in the realm R2
      would have to know what information system is in use in R1, how to reach
      it, how to read and eventually how to map data from it. Moreover
      security related aspects on the authentication of S2 by the directory
      D1, the authorization of S2 to make such a query, the protection of
      responses from D1 to S2, and so on, would have to be addressed.</t>

      <t>This use-case illustrates the need for a common PAD structure to
      address this cross-realm authorization problem. In particular, the PAD
      structure for the cross-realm access to remote services needs to be
      contained or carried within cross-realm TGTs and service-tickets. Such a
      PAD structure needs to carry enough authorization information such that
      a decision can be made by service S2 in realm R2 regarding the access
      request originating from the client principal C1 within realm R1.</t>
    </section>

    <section title="A POSIX Authorization Structure for Kerberos V5">
      <section title="Attributes">
        <t>The following attributes are defined in this document:</t>

        <t><list style="symbols">
            <t>PAD-Realm</t>

            <t>PAD-DNS-Domain</t>

            <t>PAD-Short-Domain</t>

            <t>PAD-UDID</t>

            <t>PAD-Posix-Username</t>

            <t>PAD-Posix-UID</t>

            <t>PAD-Posix-GID</t>

            <t>PAD-Posix-Gecos</t>

            <t>PAD-Posix-Homedir</t>

            <t>PAD-Posix-Shell</t>

            <t>PAD-Fullname</t>

            <t>PAD-AlternateNames</t>

            <t>PAD-Groups</t>
          </list></t>

        <t>These are each defined and discussed further below.</t>
      </section>

      <section title="PAD-Realm">
        <t>The full Realm Name of the Realm the authorization information
        applies to.</t>
      </section>

      <section title="PAD-DNS-Domain">
        <t>The DNS Domain name associated to the Realm.</t>
      </section>

      <section title="PAD-Short-Domain">
        <t>A short domain name that uniquely identifies, within the set of
        trusted realms, the domain the principal belongs to. The short Domain
        name is useful for representation purposes in the OS. A KDC MUST verify
        this name is unique and correctly represnt a remote realm within its own
        realm and is allowed to change or remove this field during validation.
        This may be done to resolve name conflicts in large trust relationships.
        </t>
      </section>

      <section title="PAD-UDID">
        <t>A UDID is a Unique Domain Identifier. Ideally it universally
        identifies the domain as the one the following local identifiers
        belongs to. This is used to differentiate between local identifiers
        belonging to different domains/realms.</t>

        <t>The UDID size can be dependent on the specific Domain type and
        imlementation. However it SHOULD be not less than 96 bits long so that
        chances of conflicts are relatively low. A 96 bit long identifier
        allows to construct a 128bit account identifier by concatenating the
        UDID to the local account Identifier (32bit quantity in POSIX).</t>

        <t>For the purpose of this document the UDID is a compeltely opaque
        number and implementations SHOULD not try to perform any enforcement
        on the format of this number on receiving it.</t>
      </section>

      <section title="PAD-Posix-Username">
        <t>This is the user name that correspond to the kerberos principal,
        this is the name that SHOULD be used by the OS to represent the user.
        The OS may decide to prefix or suffix this name with the PAD-Domain or
        PAD-Realm or PAD-Short-Domain names to avoid name conflicts with
        local accounts.</t>
      </section>

      <section title="PAD-Posix-UID">
        <t>This is the UID Number associated to the user. This number is local
        to the domain identified by PAD-UDID.</t>
      </section>

      <section title="PAD-Posix-GID">
        <t>This is the Primary GID Number associated to the user. This number
        is local to the domain identified by PAD-UDID.</t>
      </section>

      <section title="PAD-Posix-Gecos">
        <t>The Gecos field for the User associated to the Principal if
        available. Can be omitted. If not available PAD-Fullname can be used
        instead.</t>
      </section>

      <section title="PAD-Posix-Homedir">
        <t>The home directory path relative to the local system, if available.
        If not available local defined defaults apply.</t>
      </section>

      <section title="PAD-Posix-Shell">
        <t>The default shell for the user, defined as the path of the binary
        relative to the local filesystem, if available. If not available local
        defined defaults apply.</t>
      </section>

      <section title="PAD-Fullname">
        <t>The full name of the user if available.</t>
      </section>

      <section title="PAD-AlternateNames">
        <t>Alternate names can be used by application to identify a user by
        means that differ from the user principal. Names are in string form
        and utf8 encoded [UTF-8]. In order to allow applications to recognize
        the name type without guesswork, alternate names are prefixed with a
        string followed by the colon ':' character and the name, without any
        space or other separation character. The following Alternate names are
        currently recognized: EMAIL, OS, OPENID, OAUTH It is allowed to
        include multiple alternate names of the same type. The order in which
        they are provided represent the priority within the same name type, if
        applications need to choose between names.</t>

        <t>(TODO: need discussion on whether these needs labeled prefixes or
        explicit attributes for each alternate representation etc...)</t>
      </section>

      <section title="PAD-Groups">
        <t>This is a structured attribute and defines the groups the principal
        is member of.</t>

        <t>The first value in the structure represents the domain UDID and is
        optional. If missing the domain UDID is assumed to be the one defined
        in the PAD-UDID attribute.</t>

        <t>Then an array of values that define the groups as follows. Each
        group value includes 3 subvalues: <list style="symbols">
            <t>(1) Name: This is the name of the group.</t>

            <t>(2) Type: Optional, type of group</t>

            <t>(3) ID: group ID.</t>
          </list> If the type is missing it is assumed that the group is of
        type "Posix Group" and the follwing ID is required and represents the
        gid number. The type is represented through a simplified OID like type
        where only 2 levels are defined. 0.0 Is reserved for posix groups, and
        the 0 prefix is reserved to official RFX use. Additional Prefixes can
        be assigned to organizations that request it for their purposes.
        Assignment TBD.</t>

        <t>Multiple PAD-Groups attributes can be present at the same time. A
        trusting KDC can augment the original user's set of groups by adding a
        new PAD-Groups structure that contains groups local to the trusting
        domain. In this case the domain UDID is required. The domain UDID is
        used for gid number conflict resolution when the PAC is transmitted
        between services of different realms.</t>

        <t>PAD-Groups are optional attributes and the KDC, upon PAC
        revalidation, may decide to remove the original attributes that do not
        belong to the KDC security domain in order to save space or to censor
        information to avoid disclosing data to services.</t>
      </section>

      <section title="PAD Mapped Attributes">
        <t>In POSIX, users and groups ID are not universally unique, and
        different Realms (even different machines within an authorization
        realm actually) may have overlapping and conflicting IDs. If this is
        the case, a trusting KDC may decide to re-map IDs coming from a
        foreign Realm to help services with uid/gid mapping and avoid ID
        conflicts that can lead to serious security issues. The original IDs
        are generally preserved.</t>

        <t>If multiple PAD buffers are received and one of them contains a
        PAD-UDID that is recognized by the application to be the local
        security domain identifier, then only the mapped attributes in this
        buffer SHOULD be used for authorization purposes.</t>
      </section>

      <section title="RFC2307 references for Directory Services backed KDCs">
        <t>A few attributes contain the keyword 'Posix' in their name. These
        attributes are usually represented by RFC2307 in Directory Services.
        If the primary store for these attributes is a Directory the following
        equivalence with RFC2307 defined attributes can be used.</t>

        <section title="PAD-Posix-Username as 'uid'">
          <t>The PAD-Posix-Username is the User ID, and its syntax is
          equivalent to the attribute named 'uid' in RFC 2307. This attribute
          is defined in RFC 4519 (2.39). The attribute is defined as
          multivalued in RFC 4519 but in this context only a single value is
          allowed. To define aliases refer to the attribute
          PAD-AlternateNames.</t>
        </section>

        <section title="PAD-Posix-UID as 'uidNumber'">
          <t>The PAD-Posix-UID is the User's Unique Identifier Number, and its
          syntax is equivalent to the attribute named 'uidNumber' in RFC
          2307.</t>
        </section>

        <section title="PAD-Posix-GID as 'gidNumber'">
          <t>The PAD-Posix-GID is the User's Primary Group Identifier Number,
          and its syntax is equivalent to the attribute named 'gidNumber' in
          RFC 2307.</t>
        </section>

        <section title="PAD-Posix-Gecos as 'gecos'">
          <t>The PAD-Posix-Gecos is the User's Common Name, although,
          traditionally, this field has been used to convey additional
          information beyond the user's full name. Its syntax is equivalent to
          the attribute named 'gecos' in RFC 2307.</t>
        </section>

        <section title="PAD-Posix-Homedir as 'homeDirectory'">
          <t>The PAD-Posix-Homedir is the User's LOCAL home directory. Its
          syntax is equivalent to the attribute named 'homeDirectory' in RFC
          2307.</t>
        </section>

        <section title="PAD-Posix-Shell as 'loginShell'">
          <t>The PAD-Posix-Shell is the User's preferred login shell. Its
          syntax is equivalent to the attribute named 'loginShell' in RFC
          2307.</t>
        </section>
      </section>
    </section>

    <section title="Validation">
      <t>The PAD information is used by a client to perform authorization,
      therefore this information is highly sensitive and must be validated to
      insure no tampering has occured.</t>
      
      <t>Therefore AD-PAD elements MUST always be transmitted contained within
      an AD-CAMMAC element</t>
      
    </section>

    <section title="Encoding">
      <t>The Kerberos protocol is defined in [RFC4120] using Abstract Syntax
      Notation One (ASN.1) [X680]. As such, this specification also uses the
      ASN.1 syntax for specifying both the abstract layout of the PAD
      attributes, as well as their encodings.</t>

      <section title="PAD Format">
        <t>The information carried in the PAD needs to be augmented by some
        identifying information in order to tie the PAD data to a specific
        identity within the Kerberos Realm.</t>

        <t>In order to allow additional authorization data to be tied together
        and at the same time always verifiable we propose that the PAD is
        delivered as an AD element within a AD-CAMMAC.</t>

        <t>An AuthorizationData element of type AD-ID-ANCHOR is used to bind
        the PAD to the ticket and the authorization data within the PAD to the
        specific principal. This element MUST always be present and SHOULD be
        validated. If this element is not available the PAD data MUST be
        discarded and considered untrustworthy.</t>
        
        <t>The AD-ID-ANCHOR includes the full principal name, the realm,
        the expiration time and an optional session ID.</t>
        
        <t>The ad-type for AD-PAD-ANCHOR is (TBD).</t>

        <t>The AD-PAD-DATA include the attributes described in paragraph 4.</t>

        <t>The ad-type for AD-PAD-DATA is (TBD).</t>

        <t>The final structure used to deliver the PAD Data looks loosely like
        the following diagram.</t>

        <figure anchor="Figure-1" title="PAD Format">
          <artwork><![CDATA[
            
            
        ==AD-CAMMAC=================================
        |------------------------------------------|
        | KDC Signature (Checksum)                 |
        |------------------------------------------|
        | Service Signature (Checksum)             |
        |------------------------------------------|
        | Trusted Service Signature (Optional)     |
        |------------------------------------------|
        | Asymmetric Key KDC Signature (Optional)  |
        |------------------------------------------|
        | /-AuthorizationData SEQUENCE:----------\ |
        | |                                      | |
        | | 0:  --AD-ID-ANCHOR----               | |
        | |    | Realm            |              | |
        | |    | PrincipalName    |              | |
        | |    | expiration time  |              | |
        | |    | session ID       |              | |
        | |     ------------------               | |
        | |                                      | |
        | | 1:  --AD-PAD-DATA------              | |
        | |    | PAD Attributes ...|             | |
        | |    | ..                |             | |
        | |     -------------------              | |
        | | ....    ....                         | |
        | | X:  --AD-XXXXXXX-------              | |
        | |    | ..                |             | |
        | |     -------------------              | |
        | \--------------------------------------/ |
        ============================================
 


          ]]></artwork>
        </figure>
      </section>
    </section>

    <section title="Data Structures and Extensions">
      <section title="AD-ID-ANCHOR">
      
        <t>The AD-ID-ANCHOR is intended to provide a means to bind data,
        carried in a AD-CAMMAC element, to a specific Identity (Principal), and
        optionally to a specific Ticket by using the session ID element.</t>
        
        <figure>
          <preamble></preamble>

          <artwork><![CDATA[
   AD-ID-ANCHOR            ::=SEQUENCE {
       p-realm             [0] Realm,
       p-name              [1] PrincipalName,
       expiration          [2] KerberosTime,
       session-id          [3] TBD
   }

   p-realm, p-name
      The realm and name of the principal the authorization data
      elements apply to.

   expiration
      The Expitration Date of the Authorization Data. Normally this is
      the same as the original TGT expiration date.

   session-id
      A random number that uniquely ties any following ticket this PAD
      Data is associated to with the original TGT Released to the user

   
      	]]></artwork>

          <postamble></postamble>
        </figure>
      </section>

      <section title="AD-PAD-DATA">

        <t>The AD-PAD-DATA data is intended to provide a means for a Kerberos
        principal credentials to carry authorization data that the receiving
        service can use to perform authorization decisions.</t>
        <figure>
          <preamble></preamble>

          <artwork><![CDATA[
   AD-PAD-ANCHOR           ::=SEQUENCE {
        TBD
   }
  
      	]]></artwork>

          <postamble></postamble>
        </figure>

      </section>

      <section title="GSS-API Authenticator Extension">
        <t>The Authenticator Checksum as defined in RFC 4121 limit the size of
        delegated credentials in the KRB_CRED message to a size of 64KiB.</t>

        <t>In order to be able to transfer larger messgaes an extension is
        defined. This extension is used in stead of the Dlght/Deleg fields,
        and the Dlght and Deleg fileds MUST not be included when this
        extensions is appended to the authenticator.</t>

        <figure>
          <preamble></preamble>

          <artwork><![CDATA[
    The extension SHALL have the following format which is drafted
    according to [draft-ietf-krb-wg-gss-cb-hash-agility]:
    
       Octet        Name      Description
      -----------------------------------------------------------------
       0..3         ExtN    A 16bit value identifying the extension.
                            Represented in big-endian order;
                            Contains the hex value 0xXXXXXXXX.
                            
       4..7         Length  The length of the Extended Delegation field.
                            Represented in big-endian order;
                            
       8..N         Data    A KRB_CRED message (N = Length + 8)

   
      	]]></artwork>

          <postamble></postamble>
        </figure>

        <t>A new flag GSS_C_EXT_DELEG_FLAG with Value X is also defined. This
        flag is used instead of GSS_C_DELEG_FLAG when the delegated
        credentials are larger then 64KiB and cannot fit in the starndard
        Deleg field.</t>

        <t>Implementors SHOULD use this Extensions and this flag only if the
        KRB_CRED message is larger than 64KiB and use the standard Deleg field
        otherwise.</t>
      </section>
    </section>

    <section title="Assigned numbers">
      <t>TBD</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="Timeouts" title="Timeouts Considerations">
      <t>Current implementations depend on very strict timeouts on obtaining AS
      Replies. In popular implementations the client will timeout if it
      doesn't receive a reply within 1 second. Adding authorization data may
      involve lookups to external (to the KDC) data sources. Implementors
      should consider whether the current timeout is still reasonbale in light
      of the additional processing KDCs may be required to do.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Although it is anticipated that the PAD structure itself will be
      carried within a ticket and thereby protected using the existing
      encryption methods on that ticket, there are a number of issues that
      have bearings on the security of the entire Kerberos realm as a whole.
      Some of these issues are as follows:</t>

      <t><list style="symbols">
          <t>UID and GID Collisions: There is always the possibilty of
          collison of numbers repressing a UID and a GID. This problem can be
          remedied to a large degree by realms using an appropriate range
          selection policy and algorithms.</t>

          <t>When collisions are detected the KDC or, alternatively, the
          receiving Service MUST be able to remap IDs so that they do not
          conflict with locally defined IDs</t>

          <t>Transit-domain issues: The PAC must be signed by the KDC that is
          attaching it to a ticket with 2 different signatures. The service
          signature so that the service can verify its KDC validated the
          contents. The KDC signature, so that the OS can ask the KDC to
          confirm the PAD has not been modified by a less trusted service. An
          optional asymmetric key signature is also allowed if Keys are
          available in order to avoid additional roundtrips. For cross-realm
          tickets the "service" signature is made with the cross-realm key.
          When a KDC receives a PAD it is allowed to modify it in any way. It
          can filter out information or add information (like group
          memberships defined locally). A KDC may also decide to change
          information in different ways depending on what service it is
          targeted to.</t>
        </list></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

      &RFC4120;

      &RFC3961;

      &RFC3962;

      <!-- &draft-ietf-krb-wg-gss-cb-hash-agility; -->
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      &RFC2119;

      &RFC3552;

      &RFC1510;

      &RFC2307;

      <reference anchor="MS-PAC">
        <front>
          <title>Microsoft MS-PAC: Privilege Attribute Certificate Data
          Structure (v20100711)</title>

          <author surname="Microsoft">
            <organization>Microsoft</organization>
          </author>

          <date month="July" year="2010" />
        </front>
      </reference>

      <reference anchor="MIT-Athena">
        <!-- the following is the minimum to make xml2rfc happy -->

        <front>
          <title>Kerberos: An Authentication Service for Open Network Systems.
          In Proceedings of the Winter 1988 Usenix Conference.
          February.</title>

          <author initials="J." surname="Steiner">
            <organization></organization>
          </author>

          <author initials="B." surname="Neuman">
            <organization></organization>
          </author>

          <author initials="J." surname="Schiller">
            <organization></organization>
          </author>

          <date year="1988" />
        </front>
      </reference>

      <reference anchor="POSIX">
        <front>
          <title>Portable Operating System Interface (POSIX.1-2008)</title>

          <author surname="The Open Group">
            <organization>The Open Group</organization>
          </author>

          <date year="2008" />
        </front>
      </reference>

      <reference anchor="X.690">
        <front>
          <title>ASN.1 encoding rules: Specification of Basic Encoding Rules
          (BER), Canonical Encoding Rules (CER) and Distinguished Encoding
          Rules (DER) - ITU-T Recommendation X.690 (ISO/IEC International
          Standard 8825-1:1998)</title>

          <author surname="ISO">
            <organization>ISO</organization>
          </author>

          <date year="1997" />
        </front>
      </reference>
    </references>

    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>

    <!-- Change Log

v00 2012-02-08  EBD   Initial version after the split of generalized-pac

 -->
  </back>
</rfc>
