Internet DRAFT - draft-hess-sid-ircdigest
draft-hess-sid-ircdigest
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-<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.
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-<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:
<auth-name>:<cookie>:<md5_digest_of_secret>
* 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:
:<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
protocol.
J. Hess [Page 5]
INTERNET-DRAFT IRC Digest authentication September 17, 2000
The following numeric command responses are added:
650 RPL_DIGESTTYPES
":<type>[/<version>]{<space><type>[/<version>]}"
651 RPL_READYFORAUTH
":<token>/<digest type> <protocol version>/<command>
<cookie>"
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 <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
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]
