One document matched: draft-ietf-abfab-eapapplicability-00.xml

<?xml version = '1.0'?>
<?rfc rfcedstyle='yes'?>
<?rfc rfcprocack='yes'?>
<?rfc toc='yes'?>
<?rfc symrefs='yes'?>
<!DOCTYPE rfc SYSTEM "../xml2rfc-1.35pre1/rfc2629.dtd" [

      <!ENTITY rfc793      SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml'>
      <!ENTITY rfc2119     SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
      <!ENTITY rfc4960     SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml'>
      <!ENTITY rfc2759     SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2759.xml'>
      <!ENTITY rfc3748     SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
      <!ENTITY rfc5191     SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5191.xml'>
      <!ENTITY rfc5216     SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml'>
<!ENTITY ietf-emu-chbind SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-emu-chbind.xml">
<!ENTITY hartman-emu-mutual-crypto-bind SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hartman-emu-mutual-crypto-bind.xml">

    ]>
<rfc ipr='trust200902' docName='draft-ietf-abfab-eapapplicability-00' category='std'>
  <front>
    <title abbrev="EAP Applicability" >Update to the EAP Applicability Statement for ABFAB</title>
    <author fullname="Stefan Winter" initials="S." surname="Winter" >
	<organization abbrev="RESTENA" >Fondation RESTENA</organization>
	<address>
		<postal>
			<street>6, rue Richard Coudenhove-Kalergi</street>
			<city>Luxembourg</city>
			<code>1359</code>
			<country>LUXEMBOURG</country>
		</postal>
		<phone>+352 424409 1</phone>
		<facsimile>+352 422473</facsimile>
		<email>stefan.winter@restena.lu</email>
		<uri>http://www.restena.lu.</uri>
	</address>
    </author>
    <author fullname="Joseph Salowey" initials="J." surname="Salowey" >
	<organization abbrev="Cisco" >Cisco Systems</organization>
	<address>
		<postal>
			<street>2901 3rd Ave</street>
			<city>Seattle</city>
			<state>Washington</state>
			<code>98121</code>
			<country>USA</country>
		</postal>
		<email>jsalowey@cisco.com</email>
	</address>
    </author>
    <date month="July" year="2012" />
    <area>Security Area</area>
    <workgroup>ABFAB Working Group</workgroup>
    <keyword>EAP</keyword>
    <keyword>AAA</keyword>
    <abstract>
	    <t>This document updates the EAP applicability statement from RFC3748 to reflect recent usage of the EAP protocol in application oriented use cases proposed in ABFAB</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="intro">
<t>The EAP applicability statement in <xref target="RFC3748" /> defines the scope of the Extensible Authentication Protocol to be "for use in network access authentication, where IP layer connectivity may not be available.", and states that "Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED.".</t>
<t>While some of the recommendation against usage of EAP for bulk data transport is still valid, some of the other provisions in the applicability statement have turned out to be too narrow. <xref target="otheruses" /> describes the example where EAP is used to authenticate application layer access.  <xref target="newstatement" /> provides new text to update the paragraph 1.3. "Applicability" in <xref target="RFC3748" />.</t>
	<section title="Requirements Language" anchor="reqlang">
		<t>In this document, several words are used to signify the
requirements of the specification.  The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
<xref target="RFC2119" /></t>
	</section>
    </section>
    <section title="Uses of EAP for Application-Layer Access" anchor="otheruses">

<t>Ongoing work in the IETF (abfab working group) specifies the use of EAP over GSSAPI for generic application layer access. In the past, using EAP in this context has met resistance due to the lack of channel bindings <xref target="I-D.ietf-emu-chbind" />. Without channel bindings, a peer does not know what service will be provided by the authenticator. In most network access use cases all access servers that are served by a particular EAP server are providing the same or very similar types of service.  The peer does not need to differentiate between different access network services supported by the same EAP server.</t>
<t>However as additional services use EAP for authentication, the distinction of which service is being contacted becomes more important. Consider an environment with multiple printers; if a peer printed a document in the wrong location then potentially sensitive information might be printing in a location where the user associated with the peer would be unable to retrieve it. It is also likely that services might have different security properties. For example, it might be more likely that a low-value service is compromised than some high value service. If the high-value service could be impersonated by a low-value service then the security of the overall system would be limited by the security of the lower value service.</t>
<t>This distinction is present in any environment where peers' security depends on which service they reach. However it is particularly acute in a federated environment where multiple organizations are involved. It is very likely that these organizations will have different security policies and practices. It is very likely that the goals of these organizations will not entirely be aligned. In many situations one organization could gain value by being able to impersonate another. In this environment, authenticating the EAP server is insufficient: the peer must also validate that the contacted host is authorized to provide the requested service.</t>
<t>For these reasons, channel binding MUST be implemented by peers, EAP servers and AAA servers in environments where EAP authentication is used to access application layer services. In addition, channel binding MUST default to being required by peers for non-network authentication. If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding. Operators need to carefully consider the security implications before relaxing these requirements. One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing non-network service. A device can be created that impersonates a Network Access Service to peers, but actually proxies the authentication to the service that newly accepts EAP authentications may decrease the security of this service even for users who previously used non-EAP means of authentication to the service. </t>.
<t> It is important for the application layer to prove possession of the EAP MSK between the EAP Peer and EAP Authenticator.  In addition, the application should define an channel binding attributes that are sufficient to validate that the application service is being correctly represented to the peer. </t>

        </section>
<section title="Revised EAP applicability statement" anchor="newstatement">
<t>The following text is added to the EAP applicability statement in <xref target="RFC3748" />.  </t>
<t>In cases where EAP is used for application authentication, support for EAP Channel Bindings is REQUIRED on the EAP Peer and EAP Server to validate that the host is authorized to provide the services requested.   In addition, the application MUST define channel binding attributes that are sufficient to validate that the application service is being correctly represented to the peer. It is important for the protocol carrying EAP to prove possession of the EAP MSK between the EAP Peer and EAP Authenticator.</t>
    </section>
    <section title="Security Considerations" anchor="security">
<t>In addition to the requirements discussed in the main sections of the document applications should take into account how server authentication is achieved.  Some deployments may allow for weak server authentication that is then validated with an additional existing exchange that provides mutual authentication. In order to fully mitigate the risk of NAS impersonation when these mechanisms are used, it is RECOMMENDED that mutual channel bindings be used to bind the authentications together as described in <xref target="I-D.hartman-emu-mutual-crypto-bind"></xref></t>.
    </section>
    <section title="IANA Considerations" anchor="iana">
<t>This document has no actions for IANA.</t>
    </section>
    <section title="Acknowledgements" anchor="acks"><t>Large amounts of helpful text and insightful thoughts were contributed by Sam Hartman, Painless Security.</t></section>
  </middle>
  <back>
	  <references title="Normative References">
		  &rfc2119;
		  &rfc3748;
		  &ietf-emu-chbind;
          </references>	
	  <references title="Informational References">
		  &hartman-emu-mutual-crypto-bind;
	  </references>
  </back>
</rfc>