One document matched: draft-ietf-krb-wg-anon-05.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY RFC2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>

    <!ENTITY RFC4120 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>

    <!ENTITY RFC1964 PUBLIC '' 
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1964.xml'>

    <!ENTITY RFC2743 PUBLIC '' 
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>

    <!ENTITY RFC4556 PUBLIC '' 
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4556.xml'>

    <!ENTITY RFC3852 PUBLIC '' 
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3852.xml'>

]>

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

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

<rfc ipr='full3978' updates="4120" category="std" docName="draft-ietf-krb-wg-anon-05">

<front><title abbrev="Kerberos Anonymity Support">Anonymity Support for Kerberos</title>

<author initials="L." surname="Zhu" fullname="Larry Zhu">
<organization>Microsoft Corporation</organization>
<address><postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>lzhu@microsoft.com</email></address>
</author>

<author initials="P.J." surname="Leach" fullname="Paul Leach">
<organization>Microsoft Corporation</organization>
<address>
<postal><street>One Microsoft Way</street><city>Redmond</city><region>WA</region><code>98052</code>
<country>US</country></postal>
<email>paulle@microsoft.com</email></address>
</author>

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

<area>Security</area><workgroup>NETWORK WORKING GROUP</workgroup>

<keyword>Internet-Draft</keyword>

<abstract>

<t> This document defines extensions to the Kerberos protocol for the
   Kerberos client to authenticate the Kerberos Key Distribution Center
   and the Kerberos server, without
   revealing the client's identity. It updates RFC 4120.
   These extensions can be used to secure communication between 
   the anonymous client and the server. </t>

</abstract>

</front><middle>
            
<section anchor="introduction" title="Introduction">

    <t>In certain situations, the Kerberos <xref target="RFC4120"/> client may wish to
   authenticate a server and/or protect communications without 
   revealing its own identity. For example,
   consider an application which provides read access to a research
   database, and which permits queries by arbitrary requestors.  A
   client of such a service might wish to authenticate the service, to
   establish trust in the information received from it, but might not
   wish to disclose its identity to the service for privacy reasons.</t>


<t> Extensions to Kerberos are specified in this document by which 
a client can authenticate the Key Distribution Center (KDC) and request an anonymous ticket.  The client can use the anonymous ticket to authenticate the server
and protect subsequent client-server communications. </t>

<t>By using the extensions defined in this specification, the client may reveal its identity in its initial request to its own 
KDC, but it can remain anonymous thereafter to KDCs on the cross-realm authentication path, 
and to the server with which it communicates.</t>

</section>

<section title="Conventions Used in This Document" toc="default">

<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" pageno="false" format="default"></xref>.</t>

</section>

<section anchor="defs" title="Definitions" toc="default">

<t>The anonymous Kerberos realm name
is defined as a well-known realm name based on <xref target="KRBNAM"/>. The value is 
the literal "WELLKNOWN:ANONYMOUS". An anonymous Kerberos realm name MUST
NOT be present in the transited field of a ticket.
</t>

<t> The anonymous Kerberos principal name is defined as a well-known Kerberos principal 
name based on <xref target="KRBNAM"/>. 
The value of the name-type field is KRB_NT_WELLKNOWN [KRBNAM], and the value of 
the name-string field is a sequence of two KerberosString components: "WELLKNOWN", "ANONYMOUS".</t>

<t> Note that in this specification, the anonymous principal name and realm 
are only applicable to the client in Kerberos messages, the server MUST NOT be anonymous
in any Kerberos message.</t>

<t> The anonymous ticket flag is defined as bit 14 (with the first bit being bit 0) in the TicketFlags:</t>

<figure>
    <artwork>
        TicketFlags     ::= KerberosFlags
          -- anonymous(14)
          -- TicketFlags and KerberosFlags are defined in [RFC4120]
    </artwork>
</figure>

 <t>An anonymous ticket is a ticket that has all of the following properties:</t>
 
 <t> <list style="symbols"> <t>The cname field 
     contains the anonymous Kerberos principal name.<vspace blankLines="1"/></t>

<t> The crealm field contains the client's realm name, or 
the name of the realm that issued the initial ticket for the client principal, or the anonymous realm name.<vspace blankLines="1"/></t>


<t> The anonymous ticket contains no information that can reveal the client's identity.  However
the ticket may contain the client realm, intermediate realms on the client's authentication path, and
authorization data that may provide information related to the client's identity. For example,
an anonymous principal that is identifiable only within a particular group of users 
can be implemented using authorization data and such authorization data, if included in the anonymous
ticket, shall disclose the client's membership of that group.<vspace blankLines="1"/>                                                 
     </t>

<t> The anonymous ticket flag is set. </t>

</list></t>

<t> The anonymous KDC option is defined as bit 14 (with the first bit being bit 0) in the KDCOptions:</t>
<figure>
    <artwork>
        KDCOptions      ::= KerberosFlags
          -- anonymous(14)
          -- KDCOptions and KerberosFlags are defined in [RFC4120]
    </artwork>
</figure>
<t>As described in <xref target="protodefs"/>, the anonymous KDC option
is set to request an anonymous ticket.</t>

</section>

<section anchor="protodefs" title="Protocol Description">

<t> In order to
request an anonymous ticket, the client sets the anonymous KDC option
in an Authentication Exchange (AS) or Ticket Granting Service (TGS) request. The client
can request an anonymous Ticket Granting Ticket (TGT) based on a normal TGT. Unless otherwise specified, the client can
obtain an anonymous ticket with the anonymous realm name 
only by requesting an anonymous ticket in an AS exchange with the client realm set as anonymous in the request.</t>
 
<t>If the client wishes to authenticate the KDC anonymously, it sets the client name 
as anonymous in the AS exchange and provides a
PA_PK_AS_REQ pre-authentication data <xref target="RFC4556"/> where both the 
signerInfos field and the certificates field of the SignedData <xref target="RFC3852"/> of the PA_PK_AS_REQ are 
empty. Because the anonymous client does not have an associated asymmetric key pair, 
the client MUST choose the Diffie-Hellman key agreement
 method by filling in the Diffie-Hellman domain parameters in the clientPublicValue <xref target="RFC4556"/>. </t>


<t> If the ticket in the 
PA-TGS-REQ of the TGS request is anonymous, or if
the client in the AS request is anonymous, the anonymous KDC option MUST be set
in the request. Otherwise, the KDC MUST return a KRB-ERROR message with the code KDC_ERR_BADOPTION.</t>
  
<t>Upon receiving the AS request with a PA_PK_AS_REQ <xref target="RFC4556"/> from the anonymous client, 
the KDC processes the request according to Section 3.1.2 of <xref target="RFC4120"/>.
The KDC skips the checks for the client's signature and the client's public key 
(such as the verification of the binding between the client's public key and the client name), but performs otherwise-applicable checks,
  and proceeds as normal according to <xref target="RFC4556"/>.
 For example, the AS MUST check if the client's Diffie-Hellman domain parameters are acceptable.  
The Diffie-Hellman key agreement method MUST be used and the reply key is derived according to
Section 3.2.3.1 of <xref target="RFC4556"/>. If the clientPublicValue is not present in the
request, the KDC MUST return a KRB-ERROR with the code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 
<xref target="RFC4556"/>. If all goes well, an anonymous ticket is generated
according to Section 3.1.3 of <xref target="RFC4120"/> and a PA_PK_AS_REP <xref target="RFC4556"/> pre-authentication data is
included in the KDC reply according to <xref target="RFC4556"/>. If the KDC 
does not have an asymmetric key pair, it MAY reply anonymously or reject the authentication attempt. If the KDC replies anonymously, both the 
signerInfos field and the certificates field of the SignedData <xref target="RFC3852"/> of PA_PK_AS_REP in the reply are 
empty. The server name in the anonymous KDC reply contains the name of the TGS.</t>

<t>Upon receipt of the KDC reply that contains an anonymous ticket and a PA_PK_AS_REP <xref target="RFC4556"/> pre-authentication data, the client
can then authenticate the KDC based on the KDC's signature in the PA_PK_AS_REP.  
If the KDC's signature is missing in the KDC reply (the reply is anonymous), the client MUST reject the returned ticket if it cannot
authenticate the KDC otherwise.</t>

<t> The client can use the client keys to mutually authenticate with the KDC, 
request an anonymous TGT in the AS request. And in that case,
the reply key is selected as normal according to Section 3.1.3 of <xref target="RFC4120"/>.</t>

<t>For the TGS exchange, the reply key is selected as normal according to 
Section 3.3.3 of <xref target="RFC4120"/>.</t>

<t>When policy allows, the KDC issues an anonymous ticket. Based on local policy, 
the client realm in the anonymous ticket can be the
anonymous realm name or the realm of the KDC. However, in all cases, 
the client name and the client realm in the EncTicketPart 
of the reply MUST match with the corresponding client name and the client realm
of the anonymous ticket in the reply. The client MUST use the client name and the client realm
returned in the KDC-REP in subsequent message exchanges when using the obtained anonymous ticket.</t>

 <t>When propagating authorization data in the ticket or in the enc-
   authorization-data field of the request, the TGS MUST
   ensure that the client confidentiality is not violated in the
   returned anonymous ticket.  The TGS MUST process the authorization data recursively according
   to Section 5.2.6 of <xref target="RFC4120"/> beyond the container levels such that all embedded authorization elements are 
   interpreted.
   Identity-based authorization data
   SHOULD NOT be present in an anonymous ticket in that it
   typically reveals the client's identity.  The specification of a
   new authorization data type MUST specify the processing rules of the
   authorization data when an anonymous ticket is returned.  If there is
   no processing rule defined for an authorization data element or the authorization data element is unknown,
    the TGS MUST process it when an anonymous ticket is returned as follows:</t>

   <t> <list style="symbols"> <t>  If the authorization data element may reveal the client's
      identity, it MUST be removed unless otherwise specified.<vspace blankLines="1"/></t>

   <t>  If the authorization data element is intended to restrict the use
      of the ticket or limit the rights otherwise conveyed in the
      ticket, it cannot be removed in order to hide the client's
      identity.  In this case, the authentication attempt MUST be
      rejected, and the KDC MUST return an error message with the code
      KDC_ERR_POLICY. Note this is applicable to both critical and
      optional authorization data.<vspace blankLines="1"/></t>

   <t>  If the authorization data element is unknown, the TGS MAY remove
      it, or transfer it into the returned anonymous ticket, or reject the
      authentication attempt, based on local policy for that
      authorization data type unless otherwise specified. If there is no policy defined
      for a given unknown authorization data type, the authentication MUST be rejected.  
      The error code is KDC_ERR_POLICY when the authentication is rejected.</t>
   </list></t>

   <t>The AD-INITIAL-VERIFIED-CAS authorization data <xref target="RFC4556"/> MAY be
   removed from an anonymous ticket based on local policy of the TGS.</t>


<t>The TGS MUST add the name of the previous realm according to Section 3.3.3.2 of 
<xref target="RFC4120"/>. If the client's realm is the anonymous realm, 
the abbreviation forms that build on the preceding name cannot be used at the start of the transited encoding.
The null-subfield form (e.g., encoding ending with ",") could not be used next to the anonymous realm that can potentially be at the  
beginning where the client realm is filled in.
</t>

<t> If the client is anonymous and the KDC does not have a key to encrypt the reply (this can happen when, 
for example, the KDC does not support PKINIT <xref target="RFC4556"/>), 
the KDC MUST return an error message with the code KDC_ERR_NULL_KEY <xref target="RFC4120"/>.</t>

<t> If a client requires anonymous communication then the client MUST
check to make sure that the ticket in the reply is actually anonymous by checking the
presence of the anonymous ticket flag. This is because KDCs ignore unknown KDC options. A
KDC that does not understand the anonymous KDC option will not
return an error, but will instead return a normal ticket.</t>

<t>The subsequent client and server communications then proceed as described in <xref target="RFC4120"/>.</t>

<t>A server accepting an anonymous service ticket
may assume that subsequent requests using the same ticket 
originate from the same client. Requests with different tickets are 
likely to originate from different clients.</t>
</section>

<section title="GSS-API Implementation Notes">

<t> At the GSS-API <xref target="RFC2743"/> level, the use of an anonymous principal by the initiator/client 
requires the initiator/client to assert the "anonymous" flag when 
calling GSS_Init_Sec_Context().</t>

<t> GSS-API does not know or define "anonymous credentials", so the
(printable) name of the anonymous principal will rarely be used by or relevant for the initiator/client. 
The printable name is relevant for the acceptor/server when performing an authorization decision based 
on the initiator name that is returned from the acceptor side upon the successful security context establishment.</t>

<t> A GSS-API initiator MUST carefully check the resulting context attributes from 
the initial call to GSS_Init_Sec_Context() when requesting anonymity, 
because (as in the GSS-API tradition and for backwards compatibility) 
anonymity is just another optional context attribute.  
It could be that the mechanism doesn't recognize the attribute at all or that 
anonymity is not available for some other reasons -- and in that case the initiator must NOT 
send the initial security context token to the acceptor, because it will likely reveal 
the initiators identity to the acceptor, something that can rarely be "un-done".</t>

<t> GSS-API defines the name_type GSS_C_NT_ANONYMOUS <xref target="RFC2743"/> to represent the anonymous identity.
In addition, Section 2.1.1 of <xref target="RFC1964"/> defines 
the single string representation of a Kerberos principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.
For the anonymous principals, the name component within the exportable name as defined in Section 2.1.3 of 
<xref target="RFC1964"/> MUST signify the realm name according to Section 2.1.1 of <xref target="RFC1964"/>.
Note that in this specification only the client/initiator can be anonymous.</t>

<t> Portable initiators are RECOMMENDED to use default credentials whenever possible, and 
request anonymity only through the input anon_req_flag <xref target="RFC2743"/> to GSS_Init_Sec_Context().</t>

</section>

<section anchor="securityconsideration" title="Security Considerations" toc="default">

<t> Since KDCs ignore unknown options, a client requiring anonymous communication
needs to make sure that the ticket is actually anonymous. This is because a KDC that
that does not understand the anonymous option would not return an anonymous ticket.</t>

<t>By using the mechanism defined in this specification, 
the client does not reveal its identity to the server but its identity may be revealed to the KDC 
of the server principal (when the server principal is in a different realm than that of the client), 
and any KDC on the cross-realm authentication path. The Kerberos client MUST verify the ticket being used 
is indeed anonymous before communicating with the server,
otherwise the client's identity may be revealed unintentionally.</t> 

<t>In cases where specific server principals must not have access to the client's identity 
(for example, an anonymous poll service), the KDC can define server principal specific policy
that insure any normal service ticket can NEVER be issued to any of these server principals.</t>

<t>If the KDC that issued an anonymous ticket were to maintain 
records of the association of identities to an anonymous ticket, 
then someone obtaining such records could breach the anonymity.  
Additionally, the implementations of most (for now all) KDC's respond 
to requests at the time that they are received.  
Traffic analysis on the connection to the KDC will allow an attacker to 
match client identities to anonymous tickets issued.  
Because there are plaintext parts of the tickets that are exposed on the wire, 
such matching by a third party observer is relatively straightforward.</t>

<t>The client's real identity is not revealed when the client is authenticated as the anonymous principal. Application servers
MAY reject the authentication in order to, for example, prevent information disclosure or as part of Denial of Service (DOS) prevention. Application servers MUST avoid accepting anonymous credentials 
in situations where they must record the client's identity; for example, 
when there must be an audit trail.</t>

</section>

<section title="Acknowledgements">

   <t>JK Jaganathan helped editing early revisions of this document.</t>
<t> Clifford Neuman contributed the core notions of this document.</t>

<t> Ken Raeburn reviewed the document and provided suggestions for improvements.</t>

<t> Martin Rex wrote the text for GSS-API considerations.</t>

<t> Nicolas Williams reviewed the GSS-API considerations section and suggested ideas for improvements.</t>

<t> Sam Hartman and Nicolas Williams were great champions of this work.</t>

<t>In addition, the following individuals made significant contributions: 
Jeffrey Altman, Tom Yu, Chaskiel M Grundman,
Love Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.</t>

</section>

<section title="IANA Considerations">

    <t><xref target="defs"/> defines the anonymous Kerberos name and the anonymous Kerberos realm based on 
    <xref target="KRBNAM"/>. The IANA registry for
    <xref target="KRBNAM"/> need to be updated to add references to this document. </t>

</section>

</middle>

<back>

<references title="Normative References">&RFC2119;&RFC4120;&RFC1964;&RFC2743;&RFC4556;&RFC3852;

<reference anchor='KRBNAM'>

    <front>

    <title>Kerberos Anonymity Support</title>


    <author initials='K.' surname='Raeburn' fullname='Kenneth
    Raeburn'>
        <organization>Massachusetts Institute of Technology</organization>
    </author>    

    <date year='2004' month='December'/>
    </front>
 </reference>

</references>

</back>
</rfc>