idnits 2.17.1 draft-zorn-emu-eap-pwc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2011) is 4792 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) == Outdated reference: A later version (-02) exists of draft-zorn-emu-team-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Network Zen 4 Intended status: Standards Track March 7, 2011 5 Expires: September 8, 2011 7 A Method for Changing Cleartext Passwords in the Extensible 8 Authentication Protocol 9 draft-zorn-emu-eap-pwc-00 11 Abstract 13 The Extensible Authentication Protocol (EAP) provides support for 14 multiple authentication methods. One such method is Generic Token 15 Card (EAP-GTC) which, despite its name, is commonly used to support 16 authentication using cleartext passwords in tunneled EAP methods. 17 EAP-GTC does not provide the ability to change a password (for 18 example, an expired password), however. This document defines the 19 PassWord Change EAP method (EAP-PWC) in order to fill that void in 20 functionality. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may not be modified, 26 and derivative works of it may not be created, except to format it 27 for publication as an RFC or to translate it into languages other 28 than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 8, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 61 3. EAP-PWC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 The Generic Token Card EAP method (EAP-GTC) [RFC3748] is commonly 71 used to support authentication using cleartext passwords in tunneled 72 EAP methods. However, EAP-GTC does not provide the ability to change 73 a password (for example, one which is about to expire). This 74 document defines the PassWord Change EAP method (EAP-PWC) in order to 75 fill that void in EAP functionality. 77 2. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 3. EAP-PWC 85 Description 87 If the EAP authenticator determines that the password should be 88 changed as a result of the evaluation of the EAP/Identity 89 response, it SHOULD send an EAP-PWC/Request to the peer. The 90 Request contains a pair of displayable messages separated by the 91 NUL character (0x00) and the Response contains the old and new 92 passwords, also separated by a single NUL character. A Response 93 MUST be sent in reply to the Request. The Response MUST be of 94 Type (PWC), Nak (Type 3), or Expanded Nak (Type 254) 95 [RFC3748]. The Nak Response indicates the peer's desired 96 authentication Type(s). The EAP-PWC method MUST NOT be used to 97 provide support for cleartext password change in the absence of a 98 protected tunnel with server authentication (e.g., TEAM 99 [I-D.zorn-emu-team]). 101 Type 103 105 Type-Data 107 The Type-Data field in the Request contains a displayable message 108 concatenated with a single NUL character concatenated with a 109 displayable message. Each of the messages MUST be individually 110 processed according to the rules of the [RFC4013] profile of 111 [RFC3454] before the concatenation is performed. The messages 112 SHALL be considered to be "stored strings" per [RFC3454], and 113 unassigned code points are therefore prohibited. The output SHALL 114 be the binary representation of the processed UTF-8 character 115 string. Prohibited output and unassigned codepoints encountered 116 in SASLprep pre-processing SHALL cause a failure of pre- 117 processing, and the output SHALL NOT be used with EAP-PWC. 119 The Type-Data field in the Response contains the old password 120 concatenated with a single NUL character concatenated with the new 121 password. Each of the strings MUST be individually processed 122 according to the rules of the [RFC4013] profile of [RFC3454] 123 before the concatenation is performed. The passwords SHALL be 124 considered to be "stored strings" per [RFC3454], and unassigned 125 code points are therefore prohibited. The output SHALL be the 126 binary representation of the processed UTF-8 character string. 127 Prohibited output and unassigned codepoints encountered in 128 SASLprep pre-processing SHALL cause a failure of pre-processing, 129 and the output SHALL NOT be used with EAP-PWC. 131 Security Claims 133 Auth. mechanism: Cleartext password 134 Ciphersuite negotiation: No 135 Mutual authentication: No 136 Integrity protection: No 137 Replay protection: No 138 Confidentiality: No 139 Key derivation: No 140 Key strength: N/A 141 Dictionary attack prot.: No 142 Fast reconnect: No 143 Crypto binding: N/A 144 Session independence: N/A 145 Fragmentation: No 146 Channel binding: No 148 4. Security Considerations 150 The EAP-PWC method MUST NOT be used in the absence of a 151 cryptographically protected tunnel with server authentication. 153 5. IANA Considerations 155 This memo requires IANA to allocate a new EAP method type for EAP- 156 PWC. The placeholder indicated by in Section 3 above shall be 157 replaced by the new EAP method type upon assignment by IANA. 159 6. References 160 6.1. Normative References 162 [RFC2119] Bradner, S., "Key words for use in RFCs to 163 Indicate Requirement Levels", BCP 14, RFC 2119, 164 March 1997. 166 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 167 Internationalized Strings ("stringprep")", 168 RFC 3454, December 2002. 170 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, 171 J., and H. Levkowetz, "Extensible Authentication 172 Protocol (EAP)", RFC 3748, June 2004. 174 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for 175 User Names and Passwords", RFC 4013, 176 February 2005. 178 6.2. Informative References 180 [I-D.zorn-emu-team] Zorn, G., Wu, W., and D. Harkins, "The Tunneled 181 Extensible Authentication Protocol Method 182 (TEAM)", draft-zorn-emu-team-01 (work in 183 progress), October 2010. 185 Author's Address 187 Glen Zorn 188 Network Zen 189 227/358 Thanon Sanphawut 190 Bang Na, Bangkok 10260 191 Thailand 193 Phone: +66 (0) 87-040-4617 194 EMail: gwz@net-zen.net