<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY RFC4072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml">
<!ENTITY RFC3579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml">
<!ENTITY I-D.nir-tls-eap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nir-tls-eap.xml">
<!ENTITY I-D.howlett-eap-gss SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.howlett-eap-gss.xml">
]>
<rfc category="std" docName="draft-tschofenig-moonshot-ps-01.txt" ipr="trust200902">
  <front>
    <title abbrev="Federated Auth. Beyond The Web: PS">Federated Authentication Beyond The Web:
      Problem Statement and Requirements</title>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
    <date year="2010"/>
    <area>Internet</area>
    <workgroup>MOONSHOT</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>Federated Authentication</keyword>
    <keyword>AAA</keyword>
    <keyword>RADIUS</keyword>
    <keyword>Diameter</keyword>
    <keyword>GSS-API</keyword>
    <keyword>EAP</keyword>
    <keyword>SASL</keyword>
    <abstract>
      <t>It is quite common that application developers and system architects are in need for
        authentication and authorization support in a distributed environment. At least three
        parties need to cooperate, namely the end host, the identity provider, and the relying
        party. At the end of the exchange the identity provider asserts identity information or
        certain attributes to the relying party without exposing the user's long-term secret to the
        relying party. </t>
      <t>Although the problem sounds challenging and interesting, it is not new. In fact, various
        IETF groups have produced specifications to solve this problem, such as Kerberos, RADIUS,
        and Diameter. Outside the IETF various Single-Sign-On solution for HTTP-based applications
        have been developed as well. </t>
      <t> The reader might therefore wonder about the need for new work given the existence of
        readily available solutions. This document tries to answer this question in a compact
        fashion. Note that the description in this document focuses on the scope of the new work as
        part of the "Federated Authentication Beyond The Web" BOF being proposed rather than what
        could be theoretically done. </t>
    </abstract>
  </front>

  <middle>
    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="introduction" title="Introduction">

      <t>The typical setup for a three party protocol involves the End-host, 
      the identity-provider and relying party as illustrated in <xref
        target="framework"/>. 
      It might be of surprise that there are actually four parties shown 
        in <xref
          target="framework"/>; we will address the invisible party in the middle a 
      little bit later.
      </t>

      <t>With three party protocols there are a number of different protocol variants possible, as
        the available crypto-literature shows. We will not discuss the different options in this
        document. What is relevant is that a real world entity is behind the end host and
        responsible for establishing some form of contract with the identity provider, even if it is
        only as weak as completing a web form and confirming the verification email. The outcome of
        this initial registration step is that credentials are made available to the identity
        provider and to the end host (or the user). It is important to highlight that in some
        scenarios there might indeed be a human behind the device denoted as end host and in other
        cases there is no human involved in the actual protocol execution.</t>

      <t>We assume that the identity provider and the relying party belong to different
        administrative domains. Very often there is some form of relationship between the identity
        provider and the relying party. This is particularly important when the relying party wants
        to use information obtained from the identity provider for authorization decisions and when
        the identity provider does not want to release information to every relying party (or only
        under certain conditions). While it is possible to have a bilateral agreement between every
        identity provider and every relying party; on an Internet scale this setup does require some
        intermediary, the "stuff-in-the-middle". Please note that the lack of scalability is not
        caused by technical limitations but rather by business limitations since the agreements
        between identity providers and the relying parties are often business contracts that are financially motivated.
        The "stuff-in-the-middle" is a placeholder for technical interoperability
        as well as business practices and operational arrangements, many aspects are outside the
        scope of the IETF. </t>
      <t>
        <list style="empty">

          <t>Agreed terminology for what is labeled as generically "stuff-in-the-middle" is
            unfortunately not available. Sometimes the term "identity federation", or "trust
            framework" are used. To make it worse, different terminology is used when looking at
            specific protocols.</t>
        </list>
      </t>


      <t>
        <figure title="Three Party Authentication Framework" anchor="framework">
          <artwork><![CDATA[
                         -----
                       /-     -\
                     //         \\
                     /           \
        ----        |             |        ----
    ///-    -\\\   |               |   ///-    -\\\
   /            \  |   Stuff-in-   |  /            \
  |              |-+   the-Middle  +-|              |
  |   Identity   | |               | |  Relying     |
  |   Provider   | |               | |  Party       |
  |              |  |             |  |              |
   \            /    \           /    \            /
    \\\-    -///     \\         //     \\\-    -///
        ----           \-     -/           ----
            <            -----              >
             \                             /
              \                           /
               \                         /
               \                        /
                \                      /
                 \                    /
                  \  +------------+  /
                   \ |            | /
                    v|  End Host  |v
                     |            |
                     |            |
                     +------------+
]]></artwork>
        </figure>
      </t>

      <t>Designing new three party authentication and authorization protocols is hard and
        cryptographic flaws common in designs. Achieving widespead deployment is even more
        difficult. The HTTP-based Web has enjoyed a lot of attention from the industry with respect
        to this problem and some amount of success can be noticed even though many of the business
        aspects with the "stuff-in-the-middle" still has to be sorted out. This document does not
        focus on an HTTP-based environment and instead focuses on those protocols where HTTP is not
        used. Despite the increased excitement for layering every protocol on top of HTTP there are
        still a number of protocols available that do not use HTTP-based transports. Many of these
        protocols are lacking an authentication and authorization framework of the style shown in
          <xref target="framework"/>.</t>

      <t>Interestingly, for network access authentication the usage of the AAA framework with RADIUS
          <xref target="RFC2865"/> and Diameter <xref target="RFC3588"/> was quite successful from a
        deployment point of view. To map the terminology used in <xref target="framework"/> to the
        AAA framework the identity provider corresponds to the AAA server, the relying party
        corresponds to the AAA client, and the "stuff-in-the-middle" are AAA proxies and relays
        (particularly if they are operated by third parties, such as AAA brokers and clearing
        houses). The front-end, i.e. the end host to AAA client communication, is in case of network
        access authentication offered by link layer protocols that forward authentication protocol
        exchanges back-and-forth.</t>

      <t>Is it possible to design a system that builds on top of successful protocols to offer
        non-Web-based protocols with a solid starting point for authentication and authorization in
        a distributed system? </t>

    </section>


    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="terminology" title="Terminology">
      <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="Assumptions and Requirements">

      <t>Some requirements restrict the solution space more than others. In this particular case the
        main requirement is to re-use an existing infrastructure, namely the AAA framework. Briefly
        stated: The solution MUST make use of the AAA infrastructure (RADIUS and Diameter). Ideally,
        modifications at AAA servers SHOULD be kept at a minimum. Modifications to the AAA
        infrastructure that affect operational aspects MUST NOT be made.</t>

      <t>The next requirement concerns security: The relying party MUST NOT get in possession of the
        long-term secret of the entity that is authenticated towards the AAA server. Since there is
        no single authentication mechanism that will be used everywhere there is another associated
        requirement: The authentication framework MUST allow for the flexible integration of
        authentication mechanisms. </t>

      <t>
        <list style="empty">
          <t>
            Those who are familiar with the AAA framework might realize that 
            the choices are limited. The standardized Extensible Authentication 
            Protocol (EAP) framework <xref target="RFC3748"/> fits the above requirements and is 
            widely deployed.</t>
        </list>
      </t>

      <t>Assuming that this design decision is taken for granted the remaining work is with the
        integration of the AAA infrastructure into non-Web-based application protocols. <xref
          target="front-end"/> illustrates it graphically.</t>


      <t>
        <figure title="Front-End Integration" anchor="front-end">
          <artwork><![CDATA[
                                  +--------------+ business
                                  |AAA Server    | agreements
                                  |(Identity     | <......+
                                  |Provider)     |        .
                                  |              |        .
                                  +------------+-+        .
                                  --^----------|--   .    .
                             /////  |          |  \\\\\   .
                           //       |          |       \\ . ***
                          |         |  AAA     |         |. back-
                          |         | protocol |         |. end
                          |         |          |         |. ***
                           \\       |          |       // .
                             \\\\\  |          |  /////   .
                                  --|----------|--   .    .
                  Authentication    |          |          .
                  and Security      |          v          .
 +-------------+  Layer           +-+----------+--+       .
 |             |<---------------->|               |<-.....+
 | Application |                  | Server Side   |
 | @ End Host  |  Application     | Application   |
 |             |<================>|(Relying Party)|
 +-------------+  Application     +---------------+
                  Data

                  *** front-end ***
            ]]></artwork>
        </figure> 
      </t>
      <t>The front-end (end host to relying party) communication MUST be integrated into the
        authentication framework available to the back-end. As argued previously the end-to-end
        authentication framework is EAP. Although EAP support is already integrated in AAA systems (see <xref target="RFC3579"/> and <xref target="RFC4072"/>) the
        challenge remains to carry EAP payloads from the end host to the relying party using some
        mechanism.</t>

      <t><list style="empty">
        <t>For illustrative purposes, some examples of the front-end protocols suitable for carrying EAP are "TLS using EAP Authentication" <xref target="I-D.nir-tls-eap"/>, and GSS-API Mechanism for the EAP <xref target="I-D.howlett-eap-gss"/>.</t>
      </list></t>
      <t>
        The changes to the end host and the changes to the relying party
        SHOULD be kept at a minimum.  A mechanism that can
        demonstrate deployment benefits (based on ease of update of existing
        software, low implementation effort, etc.) MUST be preferred. There MAY be a need
        to specify multiple mechanisms to support the range of different
        deployment scenarios.
        </t>
    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="sec-cons" title="Security Considerations">
      <t>This entire document is about security.</t>
    </section>


    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="iana" title="IANA Considerations">
      <t>This document does not require actions by IANA.</t>
    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section title="Acknowledgments">
      <t>The author would like to thank Sam Hartman for a discussion about all aspects of the
        "Federated Authentication Beyond The Web" effort when he was visiting MIT in June 2010.</t>
      <t>I would like to thank Mayutan Arumaithurai and	Klaas Wierenga for their feedback.</t>
    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->
  </middle>

  <!-- ////////////////////////////////////////////////////////////////////////////////// -->

  <back>
    <references title="Normative References"> 
      &RFC2119; &RFC2865; &RFC3588;
      &RFC3748;  &RFC3579; &RFC4072; 
    </references>
    
    <references title="Informative References"> 
      &I-D.nir-tls-eap;
      &I-D.howlett-eap-gss;
    </references>
  </back>
</rfc>
