One document matched: draft-zorn-emu-eap-pwc-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3748 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc4013 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4013.xml">
<!ENTITY rfc3454 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3454.xml">
<!ENTITY I-D.zorn-emu-team PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zorn-emu-team.xml">
]>
<?rfc strict="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc editing="no"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc rfcprocack="no"?>
<?rfc tocindent="yes"?>
<rfc category="std" docName="draft-zorn-emu-eap-pwc-00" ipr="noModificationTrust200902">
	<front>
		<title abbrev="EAP-PWC">A Method for Changing Cleartext Passwords in the Extensible Authentication Protocol</title>
		<author fullname="Glen Zorn" initials="G" surname="Zorn">
			<organization>Network Zen</organization>
			<address>
				<postal>
					<street>227/358 Thanon Sanphawut</street>
					<city>Bang Na</city>
					<region>Bangkok</region>
					<code>10260</code>
					<country>Thailand</country>
				</postal>
				<phone>+66 (0) 87-040-4617</phone>
				<email>gwz@net-zen.net</email>
			</address>
		</author>
		<date year="2011"/>
		<abstract>
			<t>
				The Extensible Authentication Protocol (EAP) provides support for
				multiple authentication methods.  One such method is Generic Token Card (EAP-GTC) which, despite its name, is 
				commonly used 
				to support authentication using cleartext passwords in tunneled EAP methods.  EAP-GTC does not provide the ability 
				to change a password
				(for example, an expired password), however.  
				This document defines the PassWord Change EAP method (EAP-PWC) in order to fill that void in functionality. 
			</t>
		</abstract>
	</front>
	<middle>
		<section title="Introduction">
			<t>
				The Generic Token Card EAP method (EAP-GTC) <xref target="RFC3748"/>
				is commonly used 
				to support authentication using cleartext passwords in tunneled EAP methods.  However, EAP-GTC does not 
				provide the ability to change a password
				(for example, one which is about to expire).   
				This document defines the PassWord Change EAP method (EAP-PWC) in order to fill that void in 
				EAP functionality. 
			</t>
		</section>
		<section title="Requirements Language">
			<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"></xref>.
			</t>
		</section>
		<section anchor="E-P" title="EAP-PWC">
			<t>
				<list style="hanging">
					<t hangText="Description">
						<vspace blankLines="1"/>						
						If the EAP authenticator determines that the password should be changed as a result of the evaluation of the 
						EAP/Identity response, it SHOULD send an EAP-PWC/Request to the peer.
						The Request
						contains a pair of displayable messages separated by the NUL character (0x00) and the Response contains the 
						old and new passwords, also separated by a single NUL character.  A Response MUST be sent in reply to the
						Request.  The Response MUST be of Type <TBD> (PWC), Nak (Type 3), or
						Expanded Nak (Type 254) <xref target="RFC3748"/>.
						The Nak Response indicates the peer's desired authentication Type(s).  The EAP-PWC method
						MUST NOT be used to provide support for
						cleartext password change in the absence of a protected tunnel with server authentication
						(e.g., TEAM <xref target="I-D.zorn-emu-team"/>).
						<vspace blankLines="1"/>
					</t>
					<t hangText="Type">
						<vspace blankLines="1"/>
						<TBD>
						<vspace blankLines="1"/>
					</t>
					<t hangText="Type-Data">
						<vspace blankLines="1"/>
						The Type-Data field in the Request
						contains a displayable message concatenated with a single NUL character concatenated with a displayable
						message.  Each of the messages MUST be individually processed according to the
						rules of the <xref target="RFC4013"/>
						profile of <xref target="RFC3454"/> before the concatenation is performed.						
						The messages SHALL be considered to be "stored strings" per 
						<xref target="RFC3454"/>, and unassigned code
						points are therefore prohibited.  The output SHALL be the binary
						representation of the processed UTF-8 character string.
						Prohibited output and unassigned codepoints encountered in
						SASLprep pre-processing SHALL cause a failure of pre-processing,
						and the output SHALL NOT be used with EAP-PWC.
						<vspace blankLines="1"/>
						The Type-Data field in the Response
						contains the old password concatenated with a single NUL character concatenated with the new password.  		
						Each of the strings MUST be individually processed according to the
						rules of the <xref target="RFC4013"/>
						profile of <xref target="RFC3454"/> before the concatenation is performed.						
						The passwords SHALL be considered to be "stored strings" per 
						<xref target="RFC3454"/>, and unassigned code
						points are therefore prohibited.  The output SHALL be the binary
						representation of the processed UTF-8 character string.
						Prohibited output and unassigned codepoints encountered in
						SASLprep pre-processing SHALL cause a failure of pre-processing,
						and the output SHALL NOT be used with EAP-PWC.
						<vspace blankLines="1"/>						
					</t>
					<t hangText="Security Claims">
						<vspace blankLines="1"/>
						<list style="hanging" hangIndent="26">
							<t hangText="Auth. mechanism:">
							Cleartext password
							</t>
							<t hangText="Ciphersuite negotiation:">
							No
							</t>
							<t hangText="Mutual authentication:">
							No
							</t>
							<t hangText="Integrity protection:">
							No
							</t>
							<t hangText="Replay protection:">
							No
							</t>
							<t hangText="Confidentiality:">
							No
							</t>
							<t hangText="Key derivation:">
							No
							</t>
							<t hangText="Key strength:">
							N/A
							</t>
							<t hangText="Dictionary attack prot.:">
							No
							</t>
							<t hangText="Fast reconnect:">
							No
							</t>
							<t hangText="Crypto binding:">
							N/A
							</t>
							<t hangText="Session independence:">
							N/A
							</t>
							<t hangText="Fragmentation:">
							No
							</t>
							<t hangText="Channel binding:">
							No
							</t>
						</list>
					</t>
				</list>
			</t>
		</section>
		<section anchor="Security" title="Security Considerations">
			<t>
				 The EAP-PWC method
				 MUST NOT be used in the absence of a cryptographically protected tunnel with server authentication.
			</t>
		</section>
		<section title="IANA Considerations">
			<t>
				This memo requires IANA to allocate a new EAP method type for EAP-PWC.
				The placeholder indicated by <TBD> in <xref target="E-P"/> above
				shall be replaced by the new EAP method type upon assignment by IANA.
			</t>
		</section>
	</middle>
	<back>
		<references title="Normative References">
			&rfc2119;
			&rfc3748;
			&rfc4013;
			&rfc3454;
		</references>
		<references title="Informative References">
			&I-D.zorn-emu-team;
		</references>
	</back>
</rfc>