Suggested filename: draft-hess-sid-ircdigest-00.txt INTERNET-DRAFT J. Hess Expires: March 17, 2001 September 17, 2000 IRC-DIGEST Digest authentication for IRC Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo provides information for the Internet community. Abstract This document specifies a method with-which Digest Authentication can be performed between two clients over the IRC protocol and specifies a way in which digest authentication may be used by an IRC server to validate the authorization of a client attempting to connect or gain operator privileges on the server without the revealing the 'password' being used in the process to a third party packet-sniffing the connection for the very purpose of discovering it. Table of Contents 1. Introduction ......................................... 2 2. Requirements ......................................... 2 3. User-to-service - the user end ....................... 2 J. Hess [Page 1] INTERNET-DRAFT IRC Digest authentication September 17, 2000 3.1 Authentication request messages ..................... 3 3.1.1 The IDENTIFY-TYPES command ........................ 3 3.1.2 The IDENTIFY- commands .................... 3 3.1.3 The IDENTIFY-PLAIN command ........................ 3 3.1.4 The IDENTIFY-MD5 command .......................... 3 3.1.5 The challenge cookie .............................. 3 3.1.6 The response ...................................... 4 4. User-to-authservice - the service end ................ 4 4.1 Auth service message codes and text ................. 5 5. User-to-server ....................................... 5 5.1 Digest auth for access to a server .................. 6 5.2 Digest auth for privileges on a server .............. 7 5.3 Server-to-server .................................... 7 6. Security considerations .............................. 7 7. Author's address ..................................... 7 A. References ........................................... 8 B. Full Copyright Statement ............................. 8 1. Introduction The IRC (Internet Relay Chat) protocol is a commonly used protocol used by online chat systems. As any protocol, it is not perfect, IRC is particularly susceptible to packet sniffing because there are currently no provisions for transmitting encrypted messages over it. The methods specified in this document are designed to provide the ability of client-to-client, client-to-server, and server-to-server messages to contain authentication in a form that prevents a third party from either observing the password or repeating a hash to achieve the same authentication. This document does NOT specify a method for encryption of messages; it is simply a method of authentication that contains a cryptographic aspect. 2. Requirements In order for this method to be used; both ends of the authentication must understand digest authentication and be able to use the same kind of message digest. 3. User-to-service - the user end Messages to authenticate clients to clients occur within the PRIVMSG message of the IRC protocol to the service, client the user wishes to authenticate to [the one being authenticated initiates the actual authentication dialogue]. :[] PRIVMSG : [] which will cause the IRC protocol to carry the authentication message to the authenticator see the IRC protocol specification for more information. J. Hess [Page 2] INTERNET-DRAFT IRC Digest authentication September 17, 2000 3.1 Authentication request messages 3.1.1 IDENTIFY-TYPES command Usage: IDENTIFY-TYPES IDENTIFY-TYPES is a command invoked by the user that causes the authentication service to respond with a 200 message listing one or more authentication types, report some error -- if types are not listed, then it can be presumed that the destination was not an authentication service 3.1.2 IDENTIFY- commands Usage: IDENTIFY- [[] ] With no parameters the command requests a 'challenge cookie' from the authentication service. The 'digest' specified in a message with parameters is the base-16 representation a message digest (of the specified type) of a 'response' that includes three components the 'auth name' (access being authenticated for..), the 'unique cookie' (challenge sent by the auth service), and the 'password' (the secret only an authorized user of the 'auth object' knows). 3.1.3 IDENTIFY-PLAIN command Usage: IDENTIFY-PLAIN [] IDENTIFY-PLAIN is a command invoked by the user agent that simply sends the name of the object a plaintext string with no final hash. When this is used, the password is not sent over cleartext but it is possible for an authentication string to be constructed through data collected by a packet sniffer -- for debugging purposes, only, this method need-not be supported. 3.1.4 IDENTIFY-MD5 digest command This is an instance of the IDENTIFY- type that should exist in any implementation of this system. Example: When using a MD5 authentication type, and authenticating to the auth service 'NickServ' for access to the object 'joe' with a cookie 3452a, and a secret 'blah' the command would be: PRIVMSG NickServ :IDENTIFY-MD5 5ee85cef0b3e31c8e8be3b3c81937196 The final digest comes from: joe:3452a:6f1ed002ab5595859014ebf0951522d9 3.1.5 The Challenge Cookie The 'challenge cookie' must be acquired from the service by invoking the IDENTIFY- command with no other parameters or specifiers -- or the authentication service may simply issue a cookie accompanying a notice that authentication is required for some action the user has requested. J. Hess [Page 3] INTERNET-DRAFT IRC Digest authentication September 17, 2000 3.1.6 The Response The 'response' consists of the lowercased version of an auth string, the cookie string, and the base-16 representation of a MD5 Message Digest of the `secret' string [concatenated and colon-separated] in this form: :: * The reason for pre-digesting the hashed secret with MD5 is so that the authentication service can store a MD5 digest instead of the plaintext secret for password-secrecy reasons. The user must be able to take any cookie given to it by the authentication service up to the length maximum of 20 octets, but the authentication service itself should never issue a cookie that does not conform to the general rules of being 2-20 octets (inclusive) in length and containing only alphanumeric characters and the colon punctuation mark (:). Similarly, it is the auth service's duty to ensure that cookies are neither reproducible nor predictible -- a value of time() and a client id should go into the cookie to prevent reproducibility, and the remainder of the cookie should be random to prevent prediction of cookies. The 'auth-name' specifier ties the hash specifically to the object; auth-names generally consist of only lowercased strings, only printable non-space characters are sent in the auth name field, any other characters in the object are converted to underscores (_); the 'auth-name' is either the name of the object (ie: IRC user nickname), or a name agreed between the two ahead of time. 4. User-to-service - the service end The service authentication is being requested of will respond in a coded manner to minimize the amount of parsing of IRC messages needed. Messages occur within the NOTICE message of the IRC protocol and are of the form: : NOTICE : [] [- ] see the IRC protocol specification for more information. J. Hess [Page 4] INTERNET-DRAFT IRC Digest authentication September 17, 2000 4.1 Message codes and text 650 type[/]{type[/]} - List of available auth digest types - Format version 1.0 is implicit for hash types where a version is not specified. 651 / [- Ready to authenticate.] - Auth service issues the challenge after receiving an IDENTIFY request message - The only token defined by this method is 'S' to indicate digest authentication 652 [- Authentication validated] - Auth service indicates successful validation 653 [- Missing response] - Response to a second request for a cookie by the user a new cookie will be sent, getting this message tells the user to dump all cookies for that auth service. 701 [- You need a challenge first] - Response to receiving a digest before a cookie was even issued. 702 [- Invalid authenticator.] - The authentication hash was not completely valid, either the auth-name, password, or cookie component were not correct - This message may be used in place of 505 703 [- No such object.] - The user submitted an authentication for an auth object that doesn't exist. 704 [- Authentication type unsupported.] - An unsupported auth type was requested - this is the response to IDENTIFY-TYPES when no types are available or to IDENTIFY-xxx where xxx is not a supported digest. 5. User to server This section specifies an alternate implementation of digest authentication over IRC for the purpose of users authenticating to an IRC server for operator privileges; this involves the server endpoint of the IRC protocol and indicates an EXTENTION to the protocol, which differs from the previous authentication scenario where authentication was expressed within existing protocol. J. Hess [Page 5] INTERNET-DRAFT IRC Digest authentication September 17, 2000 The following numeric command responses are added: 650 RPL_DIGESTTYPES ":[/]{[/]}" 651 RPL_READYFORAUTH ":/ / " 652 RPL_AUTHVALID ":Authentication validated." 653 RPL_VOIDCOOKIE ":Missing response -- sending new auth cookie." 654 RESERVED 655 RESERVED The following numeric error responses are added: 701 ERR_NEEDCHALLENGE ":You need a cookie before you can authenticate." 702 ERR_INVALIDAUTH ":Invalid authenticator" 703 RESERVED for 'missing object' 704 ERR_UNSUPPORTED ":That authentication type is not supported." 705 RESERVED It should be noted that the numbers seem irregular, but there is a good reason for this -- there are various implementations of IRC servers use many of the numerics not defined by the IRC spec, hence for reasons of client-compatibility, there must be unique numerics. The following messages are added: Command: PASS-TYPES Parameters: PASS-TYPES Sends a RPL_DIGESTTYPES response Command: SENDAUTH Parameters: SENDAUTH Sends a message to the other side that authentication or re-authentication is necessary Command: PASS-DIGEST Parameters: PASS-DIGEST [[] []] When a digest is not specified, it causes the server to send the cookie in a RPL_READYFORAUTH numeric response, with a digest specified, authentication is performed. The digest is performed in the manner as shown in the manner shown in 3.1.6 of this document. J. Hess [Page 6] INTERNET-DRAFT IRC Digest authentication September 17, 2000 When authenticating for privileges, the 'auth name' is the nickname; when authenticating for access, the 'auth name' is the name of the IRC server. 'nick' is sent as the third parameter only if the authentication is for oper status. 5.1 Digest auth for access to a server When a server or user needs to use a password to connect to an IRC server, the PASS-DIGEST message shown above are used; the user agent should use the name of the server as-shown in the RPL_READYFORAUTH numeric as the authname; authentication for access occurs only at the beginning of each session. There is always a target nickname field in numeric response; regarding PASS-DIGEST responses though, the field must always contain something and always ignored by the server or client that receives it, and be interpreted as though addressed to itself. 5.2 Digest auth for oper access to a server A client can authenticate itself for oper privileges also through use of the PASS-DIGEST command, once the signon procedure has completed successfully. Authentication for oper privileges is performed in the same manner as the signon, except the 'auth name' is the nickname, and the nick is specified again after the digest hash in the second PASS-DIGEST command. 5.3 Server-to-server Server-to-server authentication over MD5; authentication of a valid server connect with MD5 works the same as any client access to a server, except authentication (either with digest auth, standard passwords) is always required for access. 6.1 Security considerations Generally speaking; since this is a description of a sub-protocol over IRC, the entire purpose of this is to strengthen, not reduce security. This isn't perfect; if the hash, authname, and cookie are discovered by a third party, they may be able to derive the password if it is sufficiently weak. There is no protection from man in the middle, connection hijacking, and packet sniffing attacks that breach privacy, the only way to solidly protect against these would be to introduce SSL into IRC, which would bring forth performance issues. J. Hess [Page 7] INTERNET-DRAFT IRC Digest authentication September 17, 2000 Expires: March 17, 2001 7. Authors' Addresses James Hess 12144 Dame Alley Hammond, LA 70401 Email: mysidia-223@flame.org.REMOVETHISWORD ^^^^^^^^^^^^^^^^^^^^^ Comments should go to the e-mail address above. Appendix A. References [RFC1459] J. Oikarinen, D. Reed, "Internet Relay Chat Protocol", May 1993 [RFC1321] R. Rivest, MIT Laboratory for Computer Science, RSA Data Security, Inc., "The MD5 Message-Digest Algorithm", April 1992 Appendix B. Full Copyright Statement Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." J. Hess [Page 8]