One document matched: draft-williams-kitten-krb5-pkcross-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2986 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml">
<!ENTITY rfc4120 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY rfc4556 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4556.xml">
<!ENTITY rfc5280 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc6698 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY I-D.hotz-kx509 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hotz-kx509.xml">
<!ENTITY rfc4251 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml">
]>
<rfc docName="draft-williams-kitten-krb5-pkcross-01" ipr="trust200902" category="std">
  <front>
    <title abbrev="PKCROSS">Public Key-Based Kerberos Cross Realm Path Traversal Protocol</title>
    <author initials="N." surname="Williams" fullname="Nicolas Williams">
      <organization abbrev="Cryptonector">Cryptonector, LLC</organization>
      <address>
        <email>nico@cryptonector.com</email>
      </address>
    </author>
    <date month="July" year="2013"/>
    <area>
Security Area
</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>
This document specifies a protocol for obtaining cross-realm Kerberos tickets using existing, related protocols. The resulting protocol has a number of desirable security properties, including privacy protection for the user relative to their home realm's infrastructure, as well a support for leap-of-faith trust establishment, and automated cross-realm keying. This protocol allows Kerberos to scale to large numbers of realms.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="d1e194">
      <t>
Kerberos <xref target="RFC4120"/> supports meshes of many realms. The individual relationships between realms must be manually keyed, usually with keys derived from passwords. These keys are very difficult to rollover, and when they are changed the result is often outages -- controlled outages where foreseen, but outages nonetheless. This method of cross-realm keying does not scale, and has very poor security properties. We seek to remediate this.</t>
      <t>
Many years ago there was a proposal for exchanging cross-realm keys using a public key infrastructure (PKI) <xref target="RFC5280"/>; that proposal went by the name “PKCROSS”. We appropriate that long-dead proposal's name, but the protocol specified here is very different from the original proposal.</t>
      <section title="Conventions used in this document" anchor="d1e218">
        <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>
    <section title="The Protocol" anchor="d1e234">
      <t>
A Kerberos client in with a ticket-granting ticket (TGT) for any one source realm (usually but not necessarily the client's own realm) wishing to acquire a TGT for a destination realm may use this protocol instead of the traditional cross-realm ticket-granting service (TGS) exchanges as follows:</t>
      <t>
        <list style="numbers">
          <t>
Generate private key to a public key cryptosystem;</t>
          <t>
Generate a certificate signing request (CSR) <xref target="RFC2986"/>, such that the resulting certificate has an id-pkinit-san subject alternative name (SAN) corresponding to the client's principal name and realm;</t>
          <t>
Request a certificate from the kx509 <xref target="I-D.hotz-kx509"/> service run by the source realm;</t>
          <t>
Request a TGT from the destination realm using PKINIT <xref target="RFC4556"/>.</t>
        </list>
      </t>
      <t>
If the destination realm issues the requested Ticket then it SHOULD include the client's certificate in an AD-CLIENT-CERTIFICATE authorization-data element, and it MUST do so if it does not validate the client's certificate to an acceptable trust anchor.</t>
      <t>
The destination realm MUST NOT set the TRANSIT-POLICY-CHECKED flag on the tickets they issue to clients whose foreign realm certificates are not validated by the KDC. Destination realm administrators may configure their realms to know specific foreign realm clients' certificates.</t>
      <t>
The destination MUST include the trust path of the client's certificate, if validated, in the 'transited' field of the issued Ticket, using a mapping of the issuer names to the X.500 realm naming style [XXX must specify this mapping; hopefully it can be the identity function or close enough].</t>
      <section title="Exchange of Long-Term Cross-Realm Symmetric Keys" anchor="d1e283">
        <t>
When the client principal is a TGS principal and its PKINIT AS-REQ protocol data unit (PDU) has the USE-SESSION-KEY-AS-REALM-KEY KDCOptions flag set then the client is requesting that the session key of the ticket issued by the destination realm become the long-term key for the corresponding krbtgt/DESTINATION@SOURCE principal. The destination realm MUST validate the client principal's certificate, building a trust path if need be, and validating it to a trust anchor. The source and destination realm MAY have previously exchange fingerprints of their respective key distribution service (KDC) public keys and/or certificates and/or the source realm's kx509 root or intermediate certification authority (CA), and such previously exchanged material, if any, MUST be used for certificate trust validation.</t>
        <t>
Realm administrators should use the procedure to setup symmetric cross-realm keys as necessary to save clients from having to frequently use kx509 and PKINIT as described in the preceding section.</t>
        <t>
Where public key infrastructure (PKI) exists allowing this to happen automatically, realms' KDCs MAY be configured to automatically key cross-realm principals for any realms that their source realms' clients request cross-realm TGTs for, but note that this presents a denial of service (DoS) opportunity to the source realm's clients. Source realm KDCs SHOULD only do this when a) they are configured to do so, b) the requesting client principal is in the same realm, c) the KDC has not spent too much effort recently providing this service (i.e., KDCs should throttle attempts to establish symmetric cross-realm keys in this manner), and d) up to some maximum number of cross-realm principals.</t>
      </section>
    </section>
    <section title="Privacy Protection" anchor="d1e299">
      <t>
This protocol protects the privacy of client principals vis-a-vis their home realms: client principals' home realms need not know what destination realms the clients are speaking to because client principals need not ask their home realms.</t>
    </section>
    <section title="Leap-of-Faith / TOFU" anchor="d1e308">
      <t>
Clients need not validate the certificate trust path of destination realms. When they do not, the services used through those destination realms are as good as anonymous authentication. If the client saves the root or intermediate or end entity certificates of the destination realms that it cannot or does not validate, then the client can check that on future occasions the destination realm's certificate has not changed, and it may warn the user if it has. This quite similar to how clients using the secure shell (SSH) protocol <xref target="RFC4251"/> handle server authentication, and is commonly known as “leap-of-faith” (LoF) or trust-on-first-use (TOFU). The result is as good as pseudonymous authentication.</t>
      <t>
Destination services too may apply apply LoF/TOFU: by not validating the transit path of the client (e.g., if it's not in a white-list of realms whose clients must have valid transit paths) and accepting tickets without the TRANSITED-POLICY-CHECKED ticket flag set. The destination service can save the client's certificate, if found in an AD-CLIENT-CERTIFICATE authorization-data element in the client's Ticket, and may use it later to ensure that it is talking to the same client.</t>
    </section>
    <section title="Using DNSSEC for Realm Certificate Validation" anchor="d1e326">
      <t>
[Specify how to use DNS-Based Authentication of Named Entities (DANE) <xref target="RFC6698"/> to authenticate the KDC certificates of realms with domain-style names. Roughly: format the realm's name as a domainname, then format the DANE TLSA resource record set's (RRset) domainname per-DANE, using the KDC's port number. Note that the KDCs will usually not speak TLS, though there is an extension for using TLS in the KDC over TCP protocol. For example, the TLSA RRset for any KDC for the DESTINATION.EXAMPLE realm might be named _88._tcp.destination.example.]</t>
    </section>
    <section title="Security Considerations" anchor="d1e341">
      <t>
        <cref>
...</cref>
      </t>
    </section>
    <section title="IANA Considerations" anchor="d1e350">
      <t>
        <cref>
Allocate the new KDCOptions flag (USE-SESSION-KEY-AS-REALM-KEY) and authorization-data element (AD-CLIENT-CERTIFICATE).</cref>
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">&rfc2119;
&rfc2986;
&rfc4120;
&rfc4556;
&rfc5280;
&rfc6698;
&I-D.hotz-kx509;
</references>
    <references title="Informative References">&rfc4251;</references>
  </back>
</rfc>