[2427] in Kerberos
Re: Encrypted telnet ,ftp and AFS
daemon@ATHENA.MIT.EDU (Steve Lunt)
Fri Dec 4 12:53:31 1992
Date: Fri, 4 Dec 92 12:17:26 EST
From: Steve Lunt <lunt@ctt.bellcore.com>
To: schemers@leland.stanford.edu
Cc: kerberos@Athena.MIT.EDU, ftp-wg@tgv.com
Roland,
I have done some work putting strong authentication, control
channel integrity checking, and file transfer protection into
ftp/ftpd. I submitted an informal writeup of this to the newly
formed FTP Security Working Group under IETF (ftp-wg@tgv.com). I
include below my proposal. I have these working with Kerberos V4 on
SunOS.
Your proposal is similar. I defined a new FTP command "AUTH
authentication_type". Rather than opening a separate connection, I
send authentication data (possibly two-way) over the control channel
immediately after the server accepts the AUTH command. What should
probably instead happen is the authentication data should be
exchanged as arguments to commands as the TELNET authentication
option does.
Let me know what you think. You can subscribe to the ftp-wg
list by sending mail to ftp-wg-request@tgv.com.
-- Steve
----- Begin Included Message -----
From lunt Thu Nov 19 23:31:25 1992
To: ftp-wg@tgv.com
Subject: FTP Security
FTP Security WG Members,
Please review the following proposal for strong authentication,
control channel protection, and data channel protection within FTP.
I've implemented Kerberos V4 authentication and control channel
integrity protection in ftp. I also defined three new commands,
private, safe, and clear, but haven't actually implemented them on the
server side. Please send your comments to the FTP-WG mailing list.
Thanx.
-- Steve
Steven J. Lunt Bellcore
Information Technology Security RRC 1L-213
lunt@bellcore.com 444 Hoes Lane
(908) 699-4244 Piscataway, NJ 08854
-----
I introduced the new commands AUTH, MIC, and PROT for which I
have the following description, which I could see being an amendment to
RFC959, although other parts of RFC959 need to be changed accordingly -
an exercise left to the reader :-) (mainly the state diagrams and stuff
about the format of data channels undef safe and private protection
levels).
AUTHENTICATION TYPE (AUTH)
The argument field is a Telnet string identifying a
supported authentication mechanism. The command represents
a request to perform an authentication protocol exchange
based on TYPE. Currently, only KERBEROS_V4 and KERBEROS_V5
are defined. The AUTH command is normally invoked before
the USER command. If the server accepts the authentication
type, then the client must initiate an authentication
exchange based on that authentication type immediately
following receipt of a positive reply. If the server
rejects a type, then the client may try another type, or
may continue by sending USER and PASS. If an
authentication exchange fails, another AUTH command may be
invoked. Thus, the client should request authentication
types in decreasing order of preference (i.e., strength).
If an authentication exchange succeeds, then the client's
identity has been authenticated but not yet authorized.
The client must next invoke the USER command to identify to
the server the account (file system) for which access is
requested. If the USER command succeeds (meaning that the
client is authorized), then the client must send the PASS
command to actually log the user in (the actual password is
ignored and should be a dummy value). Additional USER or
PASS commands may be sent after success of an AUTH
command.
The client should not require the server to support the
AUTH command or a particular authentication type. If
either the server does not support the AUTH command, or the
client and server cannot agree on an authentication type,
or no authentication exchange succeeds, then the default
USER and PASS commands must be performed.
The AUTH command will normally be the first command
transmitted by the user after the control connections are
made. However, the AUTH command will cause connections to
be rejected by servers which require the USER command to be
the first command transmitted by the user after the control
connection is made.
MESSAGE INTEGRITY CHECK (MIC)
After successful completion of an AUTH command and the
ensuing authentication protocol exchange, the rest of the
data over the control channel must be integrity protected
by a cryptographic checksum. All commands must be of the
form "MIC string", where "string" is a base 64 encoded
"safe" message produced by an authentication mechanism
specific message integrity procedure. The server will
decode the received string, verify its integrity via the
authentication mechanism specific message integrity
procedure, and upon success, interpret the resultant string
as an FTP command. If a failure occurs, then an
appropriate reply message is sent to the client.
PROTECTION LEVEL (PROT)
The argument is a single Telnet character code specifying
the data protection level. The PROT command is only
allowed if a previous AUTH command succeeded.
The following codes are assigned for protection levels:
C - Clear
S - Safe
P - Private
The default protection level is Safe, unless no AUTH
command succeeded, in which case the default protection
level is Clear.
When using the Safe protection level, all data sent over
the data channel is to be protected by a cryptographic
checksum (how to encode this?). When using the Private
protection level, all data sent over the data channel is
to be protected by encryption (how to encode this?). The
encoding in both cases is the same as for the MIC
command. In either case, the data normally sent over the
network is instead processed by an authentication
mechanism specific message protection procedure, and the
output is encoded in base 64. The receiver must decode
the base 64 input and process it with an authentication
mechanism specific message protection procedure. The
current representation type, file structure, and transfer
mode would still apply to the resultant data.
To implement KERBEROS_V4 authentication, I used
krb_sendauth/krb_recvauth. However, I needed to make a small fix to
sendauth, since the first thing recvauth does is read a version string,
and if the krb_mk_req call in sendauth fails, then sendauth won't send
a string, and the read in recvauth will gobble up eight bytes from the
subsequent USER ftp command. Here's the patch to lib/krb/sendauth.c:
*** ../../../athena/lib/krb/sendauth.c Mon Feb 3 12:10:43 1992
--- sendauth.c Tue Nov 10 16:25:16 1992
***************
*** 25,30 ****
--- 25,33 ----
#include <strings.h>
#define KRB_SENDAUTH_VERS "AUTHV0.1" /* MUST be KRB_SENDAUTH_VLEN chars */
+ #define KRB_SENDAUTH_BAD "KYOULOSE" /* MUST be KRB_SENDAUTH_VLEN chars */
+ /* KRB_SENDAUTH_BAD is sent if sendauth loses so that recvauth won't read
+ * past sendauth's stuff. */
/*
* If the protocol changes, you will need to change the version string
* and make appropriate changes in krb_recvauth.c
***************
*** 142,149 ****
/* get current realm if not passed in */
if (!realm) {
rem = krb_get_lrealm(krb_realm,1);
! if (rem != KSUCCESS)
return(rem);
realm = krb_realm;
}
--- 145,154 ----
/* get current realm if not passed in */
if (!realm) {
rem = krb_get_lrealm(krb_realm,1);
! if (rem != KSUCCESS) {
! krb_net_write(fd, KRB_SENDAUTH_BAD, KRB_SENDAUTH_VLEN);
return(rem);
+ }
realm = krb_realm;
}
***************
*** 156,163 ****
/* get the ticket if desired */
if (!(options & KOPT_DONT_MK_REQ)) {
rem = krb_mk_req(ticket, service, srv_inst, realm, checksum);
! if (rem != KSUCCESS)
return(rem);
}
#ifdef ATHENA_COMPAT
--- 161,170 ----
/* get the ticket if desired */
if (!(options & KOPT_DONT_MK_REQ)) {
rem = krb_mk_req(ticket, service, srv_inst, realm, checksum);
! if (rem != KSUCCESS) {
! krb_net_write(fd, KRB_SENDAUTH_BAD, KRB_SENDAUTH_VLEN);
return(rem);
+ }
}
#ifdef ATHENA_COMPAT
***************
*** 172,179 ****
/* if mutual auth, get credentials so we have service session
keys for decryption below */
if (options & KOPT_DO_MUTUAL)
! if (cc = krb_get_cred(service, srv_inst, realm, cred))
return(cc);
/* zero the buffer */
(void) bzero(buf, BUFSIZ);
--- 179,188 ----
/* if mutual auth, get credentials so we have service session
keys for decryption below */
if (options & KOPT_DO_MUTUAL)
! if (cc = krb_get_cred(service, srv_inst, realm, cred)) {
! krb_net_write(fd, KRB_SENDAUTH_BAD, KRB_SENDAUTH_VLEN);
return(cc);
+ }
/* zero the buffer */
(void) bzero(buf, BUFSIZ);
----- End Included Message -----
----- Begin Included Message -----
From shelby.stanford.edu!owner-comp-protocols-kerberos@ctt.ctt.bellcore.com Fri Dec 4 01:42:00 1992
Date: Fri, 4 Dec 92 06:28:42 GMT
From: schemers@leland.stanford.edu (Roland Schemers)
Organization: Distributed Computing Group, Stanford University
Subject: Re: Encrypted telnet ,ftp and AFS
Sender: owner-comp-protocols-kerberos@shelby.stanford.edu
To: kerberos@shelby.stanford.edu
In article <9212040516.AA18069@tsx-11.MIT.EDU> tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes:
>At the moment, there is no standardized Kerberized ftp protocol. It
>turns out that ftp is a relatively complicated protocol, and the simple,
>obvious ways of kerberizing it are not necessarily secure. There is a
As a learning experience I kerberized an ftpd and an ftp client. I did
this by adding a SITE extension called AUTH. When the client connects
to the ftpd instead of starting with a USER command it sends the command:
SITE AUTH KV4 (I've been using kerberos from DECathena)
If the server accepts this type of authorization then it opens a
binary connection to the client and the client sends the authenticator
to the server. This is what it looks like:
Slapshot:~/Work/Kerberos/kftp 3# kftp slapshot
Connected to Slapshot.Stanford.EDU.
220 Slapshot.Stanford.EDU FTP server (Version 6.57 Wed Nov 11 23:46:44 PST 1992) ready.
200 PORT command successful.
150 Opening BINARY mode data connection for kerberos authenticator.
230 User schemers.@OLYMPIA.STANFORD.EDU [36.53.0.16] logged in.
ftp>
So the authenticator is treated just like binary file, and the standard
way of sending binary data is used. I've also modified the ftpd to treat
an unknown principle as an anonymous user (as along as the normal ~ftp
account is setup).
Does this seem like a reasonable approach? I then envisioned adding
encryption and verification modes with something like:
SITE TYPE SAFE
SITE TYPE SECRET
Or something similar. Of course this means all clients and ftpds must
be modified, but it also means the modified versions can interoperate
with existing versions. For example:
Slapshot:~/Work/Kerberos/kftp 5# ftp argus
Connected to Argus.Stanford.EDU.
220 Argus.Stanford.EDU FTP server (ULTRIX Version 4.1 Tue Mar 19 00:38:17 EST 1991) ready.
200 PORT command successful.
502 SITE command not implemented.
Name (argus:schemers):
So if the ftpd doesn't understand the "SITE AUTH ..." command then the client
just falls back to prompting for the username/password.
This has just been a learning experience, but I tried to extend the ftp
protocol through SITE options, and make it extensible:
SITE AUTH KV4
SITE AUTH KV5
etc.
Are there any gaping security holes in my logic? :-)
Roland
--
Roland J. Schemers III | Networking Systems
Systems Programmer | 168 Pine Hall (415)-723-6740
Distributed Computing Group | Stanford, CA 94305-4122
Stanford University | schemers@Slapshot.Stanford.EDU
----- End Included Message -----
