[2720] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Kerberized ftp with encryption option available.

daemon@ATHENA.MIT.EDU (Steve Lunt)
Wed Jun 2 18:25:58 1993

Date: Wed, 2 Jun 93 17:52:26 EDT
From: Steve Lunt <lunt@ctt.bellcore.com>
To: yuan@syl.dl.nec.com
Cc: cat-ietf@mit.edu, kerberos@Athena.MIT.EDU

> Steve: 
> 
> I have ftped and read your internet draft on the FTP security 
> extensions. I think the proposed extensions address most of 
> of the security needs.  Two minor comments are: 
> 
>   - Sometimes, there is no clear separation between authentication
>     and authorization. Thus the commands AUTH, ADAT, USER PASS 
>     maybe organized in a different manner to address it. 

	Does the following section clear this up?  This appears under
	the definition of the ADAT command:

      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
      results in a 231 reply, then the  client  is  authorized,  and  no
      password is required.  However, the client must then send the PASS
      command to actually log  the  user  in  (the  actual  password  is
      ignored and should be a dummy value).  If the USER command results
      in a 333 reply,  then  the  user  was  not  authorized  without  a
      password,  and  a password must be sent with the PASS command.  In
      this case,  it  is  recommended  that  the  PASS  command  be  ENC
      protected.   Additional  USER  or  PASS commands may be sent after
      success of an ADAT command.

>   - On the encryption of ascii text, is it possible to have some 
>     buffering scheme to avoid encoding each charactor individully?

	Whenever encrypted (or integrity checked) data are sent over
	the control channel, the bytes are buffered, encrypted
	(processed), and sent a buffer at a time, regardless of the
	transfer type (ASCII or binary).

> BTW, how do I subscribe the mailing list cat-ietf@mit.edu? 

	Send email to cat-ietf-request@mit.edu.

> Regards,
> 
> --- Ruixi


-- Steve

Steven J. Lunt                     lunt@bellcore.com
Information Technology Security    RRC 1L-213
Bellcore                           444 Hoes Lane
(908) 699-4244                     Piscataway, NJ 08854

home help back first fref pref prev next nref lref last post