Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-newman-pwchange-00.txt < prev next >

Wrap

Text File | 1997-07-29 | 32KB | 901 lines

Network Working Group C. Newman Internet Draft: Internet Password Change Protocol Innosoft Document: draft-newman-pwchange-00.txt R. Gellens Qualcomm July 1997 Expires in six months Internet Password Change Protocol (IPCP) Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Introduction As the Internet continues to migrate from using centralized login servers to distributed client/server technology, the need for a protocol to remotely change passwords increases. Two protocols are currently in use for this purpose. Kerberos includes its own password change protocol, although client support is relatively limited. A very simple ad-hoc protocol called "poppassd" has been used in conjunction with POP [POP3] servers. This protocol is supported by many popular POP3 servers and clients but it has the unfortunate property of sending the old and new passwords in plain text over the network. This document specifies a new protocol for changing passwords or passphrases. It is based on the SASL [SASL] framework and intended to be as simple as possible while also being fully extensible. This is designed to work well with the APOP [POP3] command and Newman [Page 1] Internet Draft Internet Password Change Protocol July 1997 similar simple mechanisms to avoid sending plaintext passwords over the network whenever feasible. 1. Conventions used in this document The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "OPTIONAL" and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. The formal grammar in this document uses Augmented BNF [ABNF]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If such lines are wrapped without a new "C:" or "S:" label, then the wrapping is for editorial clarity and is not part of the command. Non-text information in examples is hex- encoded and shown in angle-brackets (e.g., "<5F601D>") for readability, although the actual exchange involves binary data transmission. 2. Protocol Overview This protocol is a simple text-based protocol. The basic concept is to use the SASL [SASL] framework with the addition of special-purpose password-change mechanisms. A protocol-level integrity service is optionally included to prevent active attacks which alter the list of available mechanisms. The protocol consists of a server greeting, followed by client commands and server responses. Clients are permitted to send multiple commands at once and will receive responses in order from the server. Commands and responses are sent as CRLF terminated lines. The protocol is designed to be extensible so that more sophisticated mechanisms can be added in the future. A simple exchange involves a server greeting, a client AUTHCHANGE command and associated SASL exchange, followed by a server acknowledgement, and a client LOGOUT command. 3. IPCP Protocol Framework This section contains the specification of the IPCP protocol. When IPCP is used over TCP/IP the server runs on port 586. The SASL Newman [Page 2] Internet Draft Internet Password Change Protocol July 1997 service name for IPCP is "ipcp". 3.1. Protocol Elements This section specifies basic components of the protocol. 3.1.1. Protocol keywords Protocol keywords are short fixed strings used to describe client commands and server responses. They have the following formal grammar: ALPHA = %x41-5A / %x61-7A ;; A US-ASCII letter KCHAR = %x21 / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E ;; All printable US-ASCII characters except SPACE, ;; <">, "(", ")", "\", and "{" keyword = ALPHA *63KCHAR 3.1.2. Quoted Strings Data sent between client and server may be represented as a quoted string. Quoted strings are surrounded by double quotes, must not exceed 1024 octets, and must not contain NUL, CR or LF. The characters <"> and "\" may be included by preceding them with "\". When quoted strings are used to represent human readable text, they are in the form of a "utf8-quoted" string [UTF8]. All other quoted strings are in the form of a regular "quoted-string" as follows: QCHAR = US-ASCII-SAFE / %x80-FF ;; UTF8 is used for text QCHAR-QUOTED = QCHAR / QUOTED QUOTED = "\" QUOTED-SPECIAL QUOTED-SPECIAL = "\" / <"> US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / %x5D-7F ;; US-ASCII except QUOTED-SPECIALs, CR, LF, NUL UTF8-NON-NUL = UTF8-SAFE / CR / LF / QUOTED-SPECIAL Newman [Page 3] Internet Draft Internet Password Change Protocol July 1997 UTF8-QUOTED = UTF8-SAFE / QUOTED UTF8-SAFE = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 UTF8-CONT = %x80-BF UTF8-1 = %xC0-DF UTF8-CONT UTF8-2 = %xE0-EF 2UTF8-CONT UTF8-3 = %xF0-F7 3UTF8-CONT UTF8-4 = %xF8-FB 4UTF8-CONT UTF8-5 = %xFC-FD 5UTF8-CONT quoted-string = <"> *QCHAR-QUOTED <"> ;; limited to 1024 octets utf8-qstring = <"> *UTF8-QUOTED <"> ;; limited to 1024 octets 3.1.3. Literal/Binary Strings Arbitrary data may be sent between the client and the server using literal strings. Literal strings begin with an unsigned 32 bit number enclosed in braces ("{", "}") representing the length, followed by a CRLF, followed by length octets, followed by the remainder of the command line. Note that non-text literal strings MAY contain a 0 or NUL octet, so implementations MUST NOT use NUL- terminated strings to store binary literal strings internally. Text literal strings are interpreted according to UTF-8. Literals have the following formal grammar: DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" OCTET = %x00-FF OCTET-NZ = %x01-FF number = 1*DIGIT ;; limited to 0 <= number < 4,294,967,296 Newman [Page 4] Internet Draft Internet Password Change Protocol July 1997 literal = "{" number "}" CRLF *OCTET ;; number indicates the number of OCTETs. ;; UTF-8 is used for text string = literal / quoted-string Servers are required to skip client literals even if a command contains a syntax error. 3.1.4. Groupings Parentheses are used to group related strings and keywords together. 3.2. Server responses Each server response begins with a slash ("/") separated hierarchical response code. The first component of the code is "OK", "NO", "BAD", "CONT" or "GOODBYE". "OK" indicates successful connection or successful completion of a client command. "NO" indicates the command failed for some reason. "BAD" indicates a protocol syntax error, usually the result of a client bug. "CONT" indicates the successful receipt of a partial command and includes server data which the client may use to continue the command. And "GOODBYE" indicates some event forced the server to close the connection. Clients MAY interpret only the first one or two hierarchical components of the response code, but MUST ignore any response detail beyond those components recognized. For responses other than "CONT", the initial response code is followed by an optional grouping of response-specific data. This is followed by a UTF-8 quoted string describing any status or errors as human readable text. After a successful AUTHCHANGE command is received (see below), a signature of the response line SHOULD be included with the response if a shared secret is present. This prevents active attacks which alter the initial greeting line or the response code. The signature is computed by taking the AUTHCHANGE random number from the client and appending the server greeting line and the current response line up to and including the space before the signature, then applying the requested signature mechanism using the original shared secret. The resulting signature is then attached as a literal to the end of the response. Newman [Page 5] Internet Draft Internet Password Change Protocol July 1997 The formal grammar for server responses follows: response = resp-continue / resp-done resp-continue = "CONT" SPACE string response-data = resp-group resp-detail = *("/" keyword) ;; MUST be registered with IANA resp-done = resp-status resp-detail [SPACE response-data] SPACE utf8-quoted [SPACE signature] resp-group = "(" resp-extend *(SPACE resp-extend) ")" resp-status = "OK" / "NO" / "BAD" / "GOODBYE" resp-extend = keyword / number / string / resp-group signature = literal ;; a signature computed over the response ;; using the algorithm specified in the AUTHCHANGE ;; command 3.3. Client Commands Client commands consist of a keyword followed by arguments. 3.4. Signature Mechanisms IPCP supports signature mechanisms for signing the server greeting and protocol response lines. The mechanism HMAC-SHA1 [HMAC, SHA1] MUST be supported and additional mechanisms can be registered with IANA. The mechanism NONE MUST be supported if any mechanisms are offered which don't involve a shared secret, but servers MAY reject NONE in combination with any mechanism that includes a shared secret. 4. Protocol Exchange This section documents the protocol exchange. Newman [Page 6] Internet Draft Internet Password Change Protocol July 1997 4.1. Server Greeting The server greeting takes the form of a response. A GOODBYE greeting indicates the server is not available and MAY include response detail indicating the reason. An OK greeting indicates the server is ready. 4.1.1. Server Referral If a server is unavailable, it may include a referral to a different server. It may be useful to run a referral-only server on a less secure system which refers to a more secure system. For example, a POP3 [POP3] client should be able connect to the IPCP port on a POP3 server and either change the password there or be refered to a proper IPCP server. This way clients don't need to be configured with an additional server. A referral is represented by a NO/REFER response with one or more domain names for the response-data. Example: S: NO/REFER ("ipcp.server.domain") "IPCP not available here" 4.1.2. Server Ready A server ready greeting is an OK/IPCP response. The response-data includes a server random string followed by capability information for the server. The "SIG-MECH" capability MUST be included and is followed by a list of signature mechanisms. The "SASL" capability MUST be included and is followed by a list of supported SASL mechanisms. Other capabilities MAY be defined by standards track or IESG approved experimental extensions to this protocol. Example: S: OK/IPCP ((SIG-MECH "HMAC-SHA1" "NONE") (SASL "SHA1-CHANGE")) "Joe's IPCP server v1.0 Ready" 4.1.3. Server Too Busy The "GOODBYE/TOOBUSY" response indicates the server is too busy to process the request at the current time. GOODBYE with no additional detail may also be used to indicate other conditions which prevent the server from accepting client commands. Example: S: GOODBYE/TOOBUSY "Server too busy at the present time" Newman [Page 7] Internet Draft Internet Password Change Protocol July 1997 4.2. AUTHCHANGE command An AUTHCHANGE command selects the IPCP signature mechanism, a random challenge for the signature mechanism, a SASL authentication and passphrase change mechanism and an optional sasl-data argument for SASL mechanisms where the client sends the first non-empty message. The command is followed by a SASL exchange with server data in the string following the "CONT" response, and client data as a single string followed by a CRLF. The authorization identity included in the SASL exchange indicates the user whose passphrase should be changed, the authentication identity indicates the user whose credentials are being used to initiate the change. This allows IPCP to be used by an administrator to set passwords for other users. The client MUST wait at least one minute for the server to issue the final success or failure response. This permits the server limited time to perform a dictionary attack on the passphrase verifier for those mechanisms which pass a one-way function applied to the passphrase. AUTHCHANGE has the following syntax: command-authchg = "AUTHCHANGE" SPACE sig-mech SPACE random SPACE sasl-mech [SPACE sasl-data] CRLF *(string CRLF) random = literal ;; client-generated random data sasl-data = string ;; A mechanism based client initial string. sasl-mech = "PLAIN-CHANGE" / "SHA1-CHANGE" / keyword ;; MUST be registered with IANA according to ;; procedures in SASL and listed in server greeting sig-mech = "HMAC-SHA1" / "NONE" / keyword ;; MUST be registered with IANA Example: [TODO - use change mechanism] S: OK/IPCP ((SIG-MECH "HMAC-SHA1" "NONE") (SASL "SHA1-CHANGE")) "Joe's IPCP server v1.0 Ready" C: AUTHCHANGE HMAC-SHA1 {20} C: <A745B67893026BC125397D4F6980D12B0402BB78> CRAM-MD5 S: CONT "<1896.697170952@postoffice.reston.mci.net>" C: "tim b913a602c7eda7a495b4e6e7334d3890" Newman [Page 8] Internet Draft Internet Password Change Protocol July 1997 S: OK "Welcome, tim" {20} S: <TODO> 4.3. Responses to AUTHCHANGE command An OK response indicates successful authentication and password change, a NO response indicates a failure at some point in the process. The response line SHOULD be signed by the server as requested by the client. The client SHOULD verify the signature on the server's response. An initial set of failure responses are listed in this section. Not all responses are appropriate for all change mechanisms. 4.3.1. NO/AUTH/FAILED response This indicates that no secret could be found for the specified user or the client's authentication did not verify correctly. There is no response to indicate unknown user in order to avoid attacks which probe for users on the system. 4.3.2. NO/AUTH/EXPIRED response This indicates that the passphrase has expired and the account owner needs to contact the system administrator for new credentials. The human readable string MAY contain contact information. 4.3.3. NO/AUTH/SUSPENDED response This indicates the account has been suspended until further notice and no access to that account of any sort is permitted. 4.3.4. NO/AUTH/ENCRYPT response This indicates the requested mechanism is not permitted unless an external encryption layer is applied. 4.3.5. NO/AUTH/TRANSITION-NEEDED response This indicates that the server has an entry for the user in a legacy authentication database from which the secret can not be recovered. It also indicates that a one-time use of the SASL PLAIN Newman [Page 9] Internet Draft Internet Password Change Protocol July 1997 [SASL-PLAIN] mechanism MAY be used by the client to initialize an entry in a newer authentication database so that future connections and password change requests can be secure. 4.3.6. NO/AUTH/SECURE-TRANSITION-NEEDED response This indicates that the server has an entry for the user in a legacy authentication database from which the secret can not be recovered. The client is required to use some secure mechanism to change the passphrase (e.g., secure remote login, or an encryption extension to this protocol) before future changes can be made. 4.3.7. NO/AUTH/UTF-8 response This indicates that the authentication or authorization user name specified did not meet UTF-8 syntax. Servers are encouraged to enforce UTF-8 syntax as this is likely to prevent non-interoperable use of non-US-ASCII characters in user names. The "NO/AUTH/FAILED" response MUST be used if the user name has valid syntax but does not exist. 4.3.8. NO/SIG/WEAK response This indicates the signature mechanism requested was too weak to meet server requirements for the specified SASL mechanism. 4.3.9. NO/SIG/NONE response This indicates the SASL mechanism specified does not support signatures and that the NONE signature mechanism has to be used instead. 4.3.9. NO/REFER response A server referral as defined in section 4.1.1. can occur in response to an AUTHCHANGE command. 4.3.10. NO/NEWPASS response This indicates that the new password does not meet site policy, syntax or authorization rules. Newman [Page 10] Internet Draft Internet Password Change Protocol July 1997 4.3.11. NO/NEWPASS/AUTHORIZE response This indicates the authenticated user does not have permission to change the password for the authorization user name specified. 4.3.12. NO/NEWPASS/UTF-8 response This indicates the new passphrase does not meet the syntax requirements for UTF-8. Servers are encouraged to enforce UTF-8 syntax as this is likely to prevent non-interoperable use of non- US-ASCII characters in passwords. 4.3.13. NO/NEWPASS/SHORT response This indicates the passphrase is too short for server requirements. The minimum length is a number at the beginning of the included response-data. 4.3.14. NO/NEWPASS/LONG response This indicates the passphrase is too long for server requirements. The maximum length is a number at the beginning of the included response-data. Maximum lengths below 64 characters are strongly discouraged. 4.3.15. NO/NEWPASS/SIMPLE response This indicates the new passphrase is too easy to guess. For example, entirely lower-case letters. 4.3.16. NO/NEWPASS/COMPLEX response This indicates the new passphrase is too complex. Specifically, it contains a character which is inappropriate for use with the supported authentication mechanisms. For example, use of the CR and LF characters in a passphrase are usually not permitted in plaintext mechanisms. 4.3.17. NO/NEWPASS/SAME response This indicates that the new passphrase is the same as the old passphrase. There is deliberately no failure error code to Newman [Page 11] Internet Draft Internet Password Change Protocol July 1997 indicate that an older passphrase is being reused. Although this may seem like a security measure, it has the effect of encouraging users to write down a series of passphrases and thus reduces the overall security of the system. 4.3.18. NO/NEWPASS/DICT response This indicates that the new passphrase was found in a server dictionary and is therefore likely to be found by a dictionary attack. The dictionary MAY include static files such as /usr/dict/words on Unix in addition to algorithms applied to the username or personal information associated with the user. 4.4. LOGOUT command The LOGOUT command indicates the client is completed. The client MAY disconnect any time after LOGOUT is successfully sent, and the server will disconnect immediately upon receipt of a LOGOUT command after any other outstanding responses have been successfully sent. The formal grammar is as follows: command-logout = "LOGOUT" CRLF 4.5. AUTH command The AUTH command is syntactically identical to the AUTHCHANGE command. It is used with regular SASL mechanisms which activate an encryption layer. For the client, the encryption layer takes effect on the first octet of the command immediately following a successful AUTH command. For the server, the encryption layer takes effect immediately after the last octet of an OK response line to the AUTH command. The AUTH command fails with a NO/AUTH/ENCRYPT error if negotiation of an encryption layer fails. The authorization identity is ignored by the AUTH command. Once an encryption layer is active clients and servers MUST NOT request another encryption layer. 5. Initial SASL mechanisms for IPCP The section defines some initial SASL change mechanisms for IPCP. All implementations of IPCP MAY support the PLAIN-CHANGE mechanism, but if supported, there MUST be a way to disable the mechanism. All server implementations which support PLAIN-CHANGE SHOULD have a way to disable the mechanism on a per-user basis in favor of Newman [Page 12] Internet Draft Internet Password Change Protocol July 1997 stronger mechanisms. All server implementations of IPCP with access to an authentication database which stores the plaintext password itself (e.g., after applying invertible encryption) MUST support the SHA1-CHANGE mechanism. All client implementations of IPCP MUST support the SHA1-CHANGE mechanism. 5.1. PLAIN-CHANGE SASL mechanism Support for the PLAIN-CHANGE mechanism is included only to support legacy authentication systems. Its use is strongly discouraged since it exposes both the old and new passphrase to a network evesdropper. This mechanism has no shared secret because the primary use of plaintext passwords is only when the server stores the plaintext password after applying a one-way function. For this reason, the NONE signature mechanism is used with the PLAIN-CHANGE SASL mechanism. The mechanism consists of a single message from the client to the server including the user whose password is to be changed, the authentication id, the passphrase for the authentication id and the new passphrase for the user, separated by US-ASCII NUL characters. The formal grammar for this mechanism is as follows: plain-change = change-user NUL auth-user NUL auth-pass NUL new-pass change-user = *UTF8-SAFE ;; if empty, then is same as auth-user auth-user = 1*UTF8-SAFE auth-pass = 1*256UTF8-SAFE new-pass = 1*256UTF8-SAFE NUL = %x00 ;; zero octet, US-ASCII NUL 5.2. SHA1-CHANGE SASL mechanism This mechanism is suitable for changing the passphrase for any mechanism which stores the passphrase on the server without applying a one-way function; such as APOP [POP3] or some implementations of CRAM-MD5 [CRAM-MD5]. Note that this mechanism is susceptible to offline dictionary attacks. Specifically, if an evesdropper records a session, that evesdropper may run values for the old password through the HMAC-SHA1 process until matching Newman [Page 13] Internet Draft Internet Password Change Protocol July 1997 output results. For this reason, it is vital to use longer and more complex passphrases. The shared secret for use with the signature mechanism is the old plaintext passphrase unencrypted. This mechanism begins with an initial server challenge. The client responds with the user whose password is to be changed, the authentication user name, a client challenge and an HMAC-SHA1 [HMAC] signature computed over the server challenge using the old passphrase. If the client's signature verifies, the server signs a string consisting of the client's challenge appended to the server's initial challenge, using the old passphrase. If the server's signature verifies, the client transmits the new passphrase using the following algorithm: (1) First, an octet representing the length of the new passphrase is pre-pended to the passphrase and this is placed in a buffer rounded up to a 20 octet boundary with arbitrary padding octets. (2) Apply HMAC-SHA1 to the server's signature using the old passphrase. (3) The output of step (2) is exclusive-ored with the first 20 octets of the buffer. If the passphrase is less than 20 octets the process completes. (4) If the buffer is longer than 20 octets, then the 20 octet output of step (3) is re-signed with the old passphrase using HMAC-SHA1. (5) The output of step (4) is exclusive ored with the next 20 octet segment of the buffer. Repeat steps (4) and (5) until done. The formal grammar for the exchange follows: server-message-1 = challenge client-message-1 = change-user NUL auth-user NUL challenge NUL signature server-message-2 = signature client-message-2 = sha1-new-pass signature = 20OCTET ;; 20 octet output of HMAC-SHA1 Newman [Page 14] Internet Draft Internet Password Change Protocol July 1997 challenge = 20*OCTET-NZ ;; randomly generated challenge with no NUL ;; octets. MUST be at least 20 octets long sha1-new-pass = 1*13xor-sig-block xor-sig-block = 20OCTET ;; signature exclusive ored with new passphrase ;; buffer as described above 6. Examples TODO 7. Security Considerations Security considerations are discussed throughout this document. Clients are encouraged to record the occurance of a successful authentication for a given user and server combination and refuse to use plain text passwords for that user and that server in the future. This will prevent a man in the middle or a spoof server from aquiring the user's password by pretending a transition is needed. Use of password change SASL mechanisms with protocols other than this one is discouraged, since general purpose application servers may not be treated with the same level of security analysis a system administrator is likely to apply to a server running a password change protocol. 8. References [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2095, MCI, January 1997. <ftp://ds.internic.net/rfc/rfc2095.txt> [HMAC] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, IBM, UCSD, February 1997. <ftp://ds.internic.net/rfc/rfc2104.txt> Newman [Page 15] Internet Draft Internet Password Change Protocol July 1997 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. <ftp://ds.internic.net/rfc/rfc2119.txt> [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. <ftp://ds.internic.net/rfc/rfc1939.txt> [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", Work in progress: draft-myers-auth-sasl-xx.txt [SASL-PLAIN] Newman, "Plaintext Password SASL Mechanism and Transition Strategy", Work in progress: draft-newman-sasl- plaintrans-xx.txt. [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, Alis Technologies, October 1996. <ftp://ds.internic.net/rfc/rfc2044.txt> 9. Authors' Addresses Chris Newman Innosoft International, Inc. 1050 East Garvey Ave. South West Covina, CA 91790 USA Email: chris.newman@innosoft.com Randall Gellens Qualcomm, Inc. 6455 Lusk Blvd. San Diego, CA 92121-2779 USA Email: Randy@Qualcomm.Com Newman [Page 16]