Internet DRAFT - draft-hess-sid-ircdigest


Suggested filename: draft-hess-sid-ircdigest-00.txt

INTERNET-DRAFT                                                   J. Hess
Expires: March 17, 2001                               September 17, 2000 

                       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 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

     The list of Internet-Draft Shadow Directories can be accessed at

     This memo provides information for the Internet community.


     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-<digest> 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].

         :[<sender>] PRIVMSG <auth_service> :<auth_command> [<parameters>]

          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-<digest> commands
          Usage: IDENTIFY-<digest_type> [[<object>] <digest>]

          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 [<object>] <secret>

          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-<digest> type that should
          exist in any implementation of this system.

          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:

3.1.5     The Challenge Cookie
          The 'challenge cookie' must be acquired from the service by
          invoking the IDENTIFY-<digest_type> 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

          Messages occur within the NOTICE message of the IRC protocol
          and are of the form:

                  :<sender> NOTICE <user> :<msgcode> [<params>] [- <info>]

          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[/<version>]{<space>type[/<version>]}
                 - List of available auth digest types
                 - Format version 1.0 is implicit for hash types where
                   a version is not specified.
             651 <token>/<digest type> <protocol version> <cookie> [-
                  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 <object> [- Authentication validated]
                 - Auth service indicates successful validation
             653 <cookie> [- 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

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
                       ":<token>/<digest type> <protocol version>/<command>
             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

         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 <digest_type> [[<digest>] [<nick>]]

            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

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
         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

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


   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

         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

         This document and the information contained herein is provided

J. Hess                                                         [Page 8]