draft-ietf-secsh-auth-kbdinteract-04.txt

Capitalization (must->MUST) and updated refs are the only changes.

Network Working Group                                          F. Cusack
INTERNET-DRAFT                                              Google, Inc.
Expires April 2, 2003                                         M. Forssen
                                                              Appgate AB
                                                         October 2, 2002

            Generic Message Exchange Authentication For SSH
               <draft-ietf-secsh-auth-kbdinteract-04.txt>

Status of this Memo

   This document is an Internet-Draft and is subject to 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>.

RE: Draft draft of coming sftp revision...

Is there a good reason for changing the relative order of times and
permissions in the file attributes?  The change makes it harder to program a
client/server that can handle either.

draft-02:

   	uint32   flags
   	uint64   size           present only if flag SSH_FILEXFER_ATTR_SIZE
   	uint32   uid            present only if flag
SSH_FILEXFER_ATTR_UIDGID
   	uint32   gid            present only if flag
SSH_FILEXFER_ATTR_UIDGID
   	uint32   permissions    present only if flag
SSH_FILEXFER_ATTR_PERMISSIONS
   	uint32   atime          present only if flag SSH_FILEXFER_ACMODTIME
   	uint32   mtime          present only if flag SSH_FILEXFER_ACMODTIME
   	uint32   extended_count present only if flag
SSH_FILEXFER_ATTR_EXTENDED
   	string   extended_type
   	string   extended_data
   	...      more extended data (extended_type - extended_data pairs),
   		   so that number of pairs equals extended_count

draft-draft:
   	uint32   flags
   	byte     type		always present
   	uint64   size           present only if flag SSH_FILEXFER_ATTR_SIZE
   	string   owner          present only if flag
SSH_FILEXFER_ATTR_OWNERGROUP
   	string   group          present only if flag

Re: Questions on reading a writing of text files....

> The draft draft contains the following:
>
> 6.4 Reading and Writing
>
>    Once a file has been opened, it can be read using the SSH_FXP_READ
>    message, which has the following format:
>
>    uint32     id
>    string     handle
>    uint64     offset
>    uint32     len
>
>    where `id' is the request identifier, `handle' is an open file handle
>    returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative
>    to the beginning of the file from where to start reading, and `len'
>    is the maximum number of bytes to read.
>
>    In response to this request, the server will read as many bytes as it
>    can from the file (up to `len'), and return them in a SSH_FXP_DATA
>    message.  If an error occurs or EOF is encountered before reading any
>    data, the server will respond with SSH_FXP_STATUS.  For normal disk
>    files, it is guaranteed that this will read the specified number of
>    bytes, or up to end of file.  For e.g.  device files this may return
>    fewer bytes than requested.
>
>    Writing to a file is achieved using the SSH_FXP_WRITE message, which
>    has the following format:
>
>    uint32     id
>    string     handle

Re: Draft draft of coming sftp revision...

Good catch.  I've reordered them.  See my
next message for more about times.

- Joseph

> Is there a good reason for changing the relative order of times and
> permissions in the file attributes?  The change makes it harder to program
a
> client/server that can handle either.
>
> draft-02:
>
>    uint32   flags
>    uint64   size           present only if flag SSH_FILEXFER_ATTR_SIZE
>    uint32   uid            present only if flag
> SSH_FILEXFER_ATTR_UIDGID
>    uint32   gid            present only if flag
> SSH_FILEXFER_ATTR_UIDGID
>    uint32   permissions    present only if flag
> SSH_FILEXFER_ATTR_PERMISSIONS
>    uint32   atime          present only if flag SSH_FILEXFER_ACMODTIME
>    uint32   mtime          present only if flag SSH_FILEXFER_ACMODTIME
>    uint32   extended_count present only if flag
> SSH_FILEXFER_ATTR_EXTENDED
>    string   extended_type
>    string   extended_data
>    ...      more extended data (extended_type - extended_data pairs),
>       so that number of pairs equals extended_count
>
>

ctime vs. Create Time

Hi all,

In the 'draft-draft' version of the sftp draft, 
I added a ctime field.  Then, in the course of
some other work I was doing, I actually looked
at what the ctime field meant.

Here is the text describing both the ctime and
mtime fields from the linux man page:

       The  field st_mtime is changed by file modifications, e.g.
       by mknod(2), truncate(2), utime(2) and write(2)  (of  more
       than  zero  bytes).   Moreover, st_mtime of a directory is
       changed by the creation  or  deletion  of  files  in  that
       directory.   The st_mtime field is not changed for changes
       in owner, group, hard link count, or mode.

       The field st_ctime is changed by  writing  or  by  setting
       inode  information  (i.e., owner, group, link count, mode,
       etc.).

Now, thats not what I thought at all!  I thought the 'c' in
ctime stood for create.  (You may even notice that in the
paragraph describing 'atime', 'ctime', and 'mtime', I said
that ctime was 'creation' time.

Under windows, the creation time of a file is stored, and I
was looking for the ability to perserve that value.

So, in my working copy I've changed ctime into 'createtime'.

RE: Questions on reading a writing of text files....

> When operating in text mode, should a read just return one line (with the
> appropriate end of line sequence), or should it fill the buffer,
separating
> each line with the end of line sequence.  What if a line has more
characters
> than are available in the buffer, should the portion that fits be returned
> and the remainder saved for the next read?
>
> There are fewer questions about writes, but what should be done with a
write
> that does not end in the end of line sequence?  Should it wait for another
> write that contains the sequence and the two be appended?

Good questions.  I was assuming the operating characteristics of read and
write would not change, which means partial lines could be both read and
written.  This is definitely the simplest way to go in terms of the amount
of verbiage needed for the draft.  (For example, line is too big for buffer
question just goes away.)

Is it too onerous to implement, do you think?

- Joseph

Partial reads are not difficult to implement.

Partial writes could be difficult to implement, depending upon VMS file
organization and whether or not the write is at the end of the file.

I think that a line stating "All end of line sequences are explicit when

Re: ctime vs. Create Time

I would much prefer that both creation and modification times be preserved.
If we're talking about copying a file intact between systems, inevitably,
there will be somebody who will have that requirement.  If the field is
common (or at least reasonably so), I always vote to preserve it if at all
possible.

For example, in VMS there are even more time fields kept for a file, although
I don't expect this standard to address those (unless you're feeling
particularly amicable today <grin>).

At 07:31 AM 10/7/2002, Joseph Galbraith wrote:
>Hi all,
>
>In the 'draft-draft' version of the sftp draft,
>I added a ctime field.  Then, in the course of
>some other work I was doing, I actually looked
>at what the ctime field meant.
>
>Here is the text describing both the ctime and
>mtime fields from the linux man page:
>
>        The  field st_mtime is changed by file modifications, e.g.
>        by mknod(2), truncate(2), utime(2) and write(2)  (of  more
>        than  zero  bytes).   Moreover, st_mtime of a directory is
>        changed by the creation  or  deletion  of  files  in  that
>        directory.   The st_mtime field is not changed for changes
>        in owner, group, hard link count, or mode.
>
>        The field st_ctime is changed by  writing  or  by  setting
>        inode  information  (i.e., owner, group, link count, mode,

Re: Questions on reading a writing of text files....

> > When operating in text mode, should a read just return one line (with
the
> > appropriate end of line sequence), or should it fill the buffer,
> separating
> > each line with the end of line sequence.  What if a line has more
> characters
> > than are available in the buffer, should the portion that fits be
returned
> > and the remainder saved for the next read?
> >
> > There are fewer questions about writes, but what should be done with a
> write
> > that does not end in the end of line sequence?  Should it wait for
another
> > write that contains the sequence and the two be appended?
>
> Good questions.  I was assuming the operating characteristics of read and
> write would not change, which means partial lines could be both read and
> written.  This is definitely the simplest way to go in terms of the amount
> of verbiage needed for the draft.  (For example, line is too big for
buffer
> question just goes away.)
>
> Is it too onerous to implement, do you think?
>
> - Joseph
>
> Partial reads are not difficult to implement.
>
> Partial writes could be difficult to implement, depending upon VMS file

sftp changes...

One important thing to note is the change
to the way version information is sent.

I talked to many of the implementation authors
directly about this change at connectathon, but
realized it had been brought up here on the list.

Previously, when the server sent its version
packet, it sent the lower of its version and
the clients version (so if the client supported
a lesser version, it echoed the clients version.)

In the current draft, the server responds with
its protocol version, and then both the client
and server use the lower of the two version numbers
sent on the wire.

This is mostly useful for debugging, where knowing
what the servers version is might be useful.

(Though I will admit, it is a bug in our implementation
as well...)

Is this going to cause problems for implmentators?  Do
currently shipping clients check the server response
to make sure it isn't higher than what they sent?

Thanks,

- Joseph

Re: ctime vs. Create Time

> I would much prefer that both creation and modification times be
preserved.
> If we're talking about copying a file intact between systems, inevitably,
> there will be somebody who will have that requirement.  If the field is
> common (or at least reasonably so), I always vote to preserve it if at all
> possible.
>
> For example, in VMS there are even more time fields kept for a file,
although
> I don't expect this standard to address those (unless you're feeling
> particularly amicable today <grin>).

Well, I might be 

I don't remember what they are though; my VMS experience is
about 10 years ago, so it is growing dimmer and dimmer.
I was trying to remember if VMS did create time and thought
that it did.  What other time fields does VMS keep?

Do you think the draft should address them?  Do you think
they are useful, even if not generally implementable?

- Joseph

>
>
> At 07:31 AM 10/7/2002, Joseph Galbraith wrote:
> >Hi all,
> >
> >In the 'draft-draft' version of the sftp draft,