One document matched: draft-perez-abfab-kerberos-preauth-options-00.xml

<?xml version="1.0" encoding="US-ASCII"?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc4120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY rfc4137 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4137.xml">
<!ENTITY rfc6113 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6113.xml">
<!ENTITY I-D.lear-abfab-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-lear-abfab-arch-02.xml">
<!ENTITY I-D.ietf-abfab-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-abfab-usecases-01.xml">
<!ENTITY I-D.perez-krb-wg-gss-preauth SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-perez-krb-wg-gss-preauth-01.xml">
]>

<rfc category="info" docName="draft-perez-abfab-kerberos-preauth-options-00" ipr="trust200902">
    <front>
        <title abbrev="Abfab-based Kerberos pre-auth">Options for Abfab-based Kerberos pre-authentication</title>
        <author fullname="Alejandro Perez Mendez" surname="Perez" initials="A" >
            <organization>University of Murcia</organization>
            <address>
                <email>alex@um.es</email>
            </address>
        </author>
        <author fullname="Josh Howlett" surname="Howlett" initials="J" >
            <organization>Janet</organization>
            <address>
                <email>josh.howlett@ja.net</email>
            </address>
        </author>
        <date year="2012" />
        <area>Security Area</area>
        <workgroup>ABFAB</workgroup>
        <abstract>
            <t>
		Kerberos is widely used for authentication within organisations. It is not, however, commonly
		used for authentication between domains or realms ("cross-realm operation"). Abfab is a new 
		architecture, based on the AAA framework, that provides a mechanism for	federating 
		authentication between realms. 
	    </t>
	    <t>
		AAA protocols are already widely used for federating authentication for network access scenarios today.
		It has been proposed that Abfab could be used to provide a mechanism yielding cross-realm
		functionality for Kerberos. This document discusses two alternative approaches with the aim
		of informing and facilitating discussion.
            </t>
        </abstract>
    </front>

    <middle>
    
        <section title="Introduction">
	    <t>
		Kerberos <xref target="RFC4120" /> is a widely deployed system for authentication,
		being integrated in multiple operating systems and network applications.  However, Kerberos is typically 
		only used to manage authentication within the scope of a single realm (typically corresponding to a
		single organisation). While often supported by implementations, Kerberos cross-realm operation is used
		relatively infrequently.
 	    </t>
	    <t>
		The Abfab architecture <xref target="I-D.lear-abfab-arch" /> describes an access management 
		model that enables the application of federated identity within a broad range of use cases.
		This is achieved by building on proven technologies and widely deployed infrastructures. 
		Some of these use cases are described in <xref target="I-D.ietf-abfab-usecases" />.
	    </t>
	    <t>
		This draft considers two new alternative approaches to typical Kerberos cross-realm operation that build 
		on the Abfab architecture. This follows previous discussion about the respective advantages and
		disadvantages of both approaches.
	    </t>
	    <t>
		The goal of this document is to describe these approaches in the expectation that this will facilitate
		and inform further discussion.
	    </t>
        </section>        

        <section title="Kerberos pre-authentication using GSS-API and an EAP mechanism">
	    <t>
		The following figure depicts this approach and its interfaces. Two organisations, the user organisation and
		the resource organisation,  are connected using a AAA infrastructure. The user organization has a Kerberos 
		infrastructure deployed to authenticate access to its local services, which is also connected to the AAA 
		infrastructure. Finally, the end user (EU) interacts with the user organisation's KDC to obtain a TGT using
		the Kerberos protocol.
	    </t>
	    <t>
		To do: figure
	    </t>
	    <t>
		The KDC acts as an EAP authenticator between the EAP peer (end user) and the EAP server (user organization 
		AAA server). Using the Kerberos pre-authentication interface, EAP frames are exchanged between these actors 
		until the authentication process is completed. If the authentication is sucessful, the end user is provided 
		with the a TGT as usual.
	    </t>
	    <t>
		Two alternative approaches for binding EAP frames to this exchange have been proposed.
	    </t>
	    <section title="EAP pre-authentication">
		<t>
		    In this approach, Kerberos itself becomes an EAP lower-layer. The most straightforward way to approach this
		    is to define a new EAP-based FAST factor. This FAST factor transports EAP packets between the EU and the KDC, 
		    following the multi round-trip procedure described in RFC6113 <xref target="RFC6113" /> (i.e. returning MORE_PREAUTH_DATA_REQUIRED error code).  
		</t>
		<t>
		    This alternative is very simple, as EAP interfaces directly with Kerberos, making the architecture more 
		    straightforward. It requires the definition of the FAST factor in such a way that implements RFC4137 <xref target="RFC4137" />, 
		    which defines the interface between EAP and the EAP lower-layer.
		</t>
	    </section>
	    <section title="GSS-API pre-authentication">
		<t>
		    In this alternative GSS-API is used by the Kerberos client and the KDC to perform pre-authentication. 
		    Hence, a pre-authentication mechanism based on the transport of GSS-API tokens is required, such as that
		    proposed by <xref target="I-D.perez-krb-wg-gss-preauth" />. Such a pre-authentication mechanism 
		    provides a generic framework where any GSS-API mechanism can be executed, without further modification 
		    to the Kerberos infrastructure.
		</t>
		<t>
		    This alternative introduces an additional layer, the GSS-API, between EAP and Kerberos. The addition of 
		    this layer implies a higher complexity of the model, but it also comes with several advantages. The 
		    first one is the flexibility it provides. Defining a generic GSS-preauth not only allows performing 
		    EAP pre-authentication, but it can be used for any other existing GSS mechanism, and for those to be 
		    defined in the future. This implies that using this alternative would serve to integrate Kerberos 
		    into any existing federation, not only those based on AAA, just by using a different GSS mechanism 
		    instead of GSS-EAP.
		</t>
		<t>
		    Besides, from an design point of view, this alternative takes advantage of the definition and 
		    implementation efforts put on the GSS-EAP mechanism of the ABFAB WG and the Moonshot project. That 
		    mechanism has already carefully implemented the interfaces defined for an EAP lower-layer.
		</t>
		<t>
		    Finally, as discussed in <xref target="I-D.perez-krb-wg-gss-preauth" />, using this proposal 
		    may simplify the generation of the PA-PX-COOKIE, as instead of serializing the whole EAP state 
		    machine on each round-trip, it could be possible to exchange GSS-API context handlers.
		</t>
	    </section>
        </section>        

        <section title="Kerberos pre-authentication using an EAP mechanism">
	    <t>
	    </t>
        </section>        

        <section title="Security Considerations">
	    <t>To do</t>
        </section>        

    </middle>

    <back>

        <references title="Informative References">
	    &I-D.lear-abfab-arch;
	    &I-D.ietf-abfab-usecases;
	    &I-D.perez-krb-wg-gss-preauth;
	    &rfc4120;
	    &rfc4137;
	    &rfc6113;
        </references>
    </back>
</rfc>