From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jul 07 21:07:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1Fz1IK-0002YX-CZ
for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Jul 2006 21:07:40 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1Fz1IJ-0006Bj-4S
for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 07 Jul 2006 21:07:40 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 3D48D63B1A4; Sat, 8 Jul 2006 01:07:37 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from vandyke.com (mail.vandyke.com [216.184.10.33])
by mail.netbsd.org (Postfix) with ESMTP id 986EE63B17A
for ; Sat, 8 Jul 2006 01:07:36 +0000 (UTC)
Received: from [127.0.0.1] (HELO [0.0.0.0])
by vandyke.com (CommuniGate Pro SMTP 3.4.7)
with ESMTP id 9196292 for ietf-ssh@netbsd.org; Fri, 07 Jul 2006 17:08:55 -0600
Message-ID: <44AEEBAD.7040606@vandyke.com>
Date: Fri, 07 Jul 2006 17:18:05 -0600
From: Joseph Galbraith
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: ietf-ssh@netbsd.org
Subject: filexfer draft ready for last call?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 1.4 (+)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
I haven't really been doing much with the filexfer draft
of late.
I'm not sure how far we'll get with a last call, but I'd
kind of like to start heading in that direction. So, if
anyone has anything that needs to be done, let's hear about
it...
Thanks,
Joseph
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Jul 09 01:28:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1FzRpz-0005F6-3v
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 09 Jul 2006 01:28:11 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1FzRpw-0004mH-0x
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 09 Jul 2006 01:28:11 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 22AB263B2A6; Sun, 9 Jul 2006 05:28:04 +0000 (UTC)
X-Original-To: ietf-ssh@NetBSD.org
Delivered-To: ietf-ssh@NetBSD.org
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])
by mail.netbsd.org (Postfix) with ESMTP id 676AC63B27E
for ; Sun, 9 Jul 2006 05:28:01 +0000 (UTC)
Received: from localhost (localhost [[UNIX: localhost]])
by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA12682;
Sun, 9 Jul 2006 01:28:00 -0400 (EDT)
Date: Sun, 9 Jul 2006 01:28:00 -0400 (EDT)
From: der Mouse
Message-Id: <200607090528.BAA12682@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
To: ietf-ssh@NetBSD.org
Subject: Re: filexfer draft ready for last call?
In-Reply-To: <44AEEBAD.7040606@vandyke.com>
References: <44AEEBAD.7040606@vandyke.com>
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73948e4d005645343fd08e813e5615ef
> I haven't really been doing much with the filexfer draft of late.
> I'm not sure how far we'll get with a last call, but I'd kind of like
> to start heading in that direction. So, if anyone has anything that
> needs to be done, let's hear about it...
What's the most recent? filexfer-12? That's the most recent I see on
ftp.ietf.org.
First, of course, it still has most of the same character-set issues it
always did. If you don't want to even read about this again, skip the
next two paragraphs.
Section 6 tries to provide a nod in the direction of dealing with
systems that don't do UTF-8, but it still demands that filenames be
character sequences, which makes it unimplementable on systems (like
traditional Unices) where filenames are octet sequences, with
conversion to and from character sequences performed elsewhere if at
all (usually by the display device and input device, and therefore (a)
in a highly user- and often context-specific manner and (b) well beyond
the power of the ssh/sftp implementation to detect). The draft
suggests using LC_CTYPE, but gives no hints on how the implementation
is supposed to detect what it is set to for the user in question - is
it expected to include a parser for the user's shell startup files?
(If indeed the user always uses the same LC_CTYPE, which may not be so.)
The simplest fix I see is to add a special charset-name for the
filename-charset extension which means, basically, "raw octet
sequences". (For concreteness, I suggest "RAW-8BIT".)
There is also a possible problem in that it appears to demand that
files contain sequences of octets. This could be a problem for, for
example, files (on, eg, a 36-bit machine) containing 9-bit bytes. I'm
not sure this is worth fixing, given today's net.
Quite aside from that, there are some other issues, mostly but not
entirely minor editorial fixes. Here are the ones I notice.
> Abstract
> The SSH File Transfer Protocol provides secure file transfer
> functionality over any reliable data stream.
s/data/octet/ here. (I'm assuming "flow-controlled" is subsumed into
"reliable".) You might also add "bidirectional" for completeness.
> This protocol provides secure file transfer (and more generally file
> system access.)
I would prefer to see the period outside the parens. I don't know
whether this is just a mistake or whether you disagree philosophically
on this point, though other sentences ending with parentheses imply the
former.
> It is designed so that it could be used to implemen=
t
> a secure remote file system service, as well as a secure file
> transfer service.
s/,//
> This protocol assumes that it runs over a secure channel, such as a
> channel in [RFC4251], and that the server has already authenticated
> the client, and that the identity of the client user is available to
> the protocol.
Strike the first "and".
> This document owes it's initial creation and protocol design to Tatu
> Ylonen and Sami Lehtinen of SSH Communications Security Corp.
s/it's/its/
> There are two packets, INIT and VERSION, which do not use the
> request-id.
> Packet descriptions in this document will contain the 'request-id=
'
> field, but will not redefine it.
I'd prefer to see a blank line in the middle here, or else these two
sentences run together into a single paragraph.
> In other words, only fields after the last
> field the implementation wishes to send are actually options.
s/options/optional/
> 5.1. Client Initialization
> If the client wishes
> to interoperate with servers that support discontinuous version
I'd prefer s/discontinuous/discontiguous/ (or perhaps noncontiguous).
> 5.4. Supported Features
> All servers MUS=
T
> include as part of their version packet.
s/as/it as/
> supported-attribute-mask
> This mask MAY by applied to the 'File Attributes' valid-attribute=
-
> flags field (Section 7.1) to ensure that no unsupported attribute=
s
> are present during a operation which writes attributes.
s/by/be/
Also, it's not clear whether this means "the client may want do this to
make things easier on the server" or "the server is allowed to silently
apply this mask".
> supported-attribute-bits
> This mask MAY by applied to the 'File Attributes' attrib-bits
s/by/be/
> case, the server is responsible for translating the clients
s/clients/client's/
> SSH_FXF_BLOCK_ADVISORY bits from Section 7.1.1.3, with a set bit
There is no section 7.1.1.3. s/7/8/?
> 7.1. valid-attribute-flags
> New fields can only be added by incrementing the protocol version
I'd prefer s/only be added/be added only/.
> 7.3. Size
> number of bytes the client intends to transfer, but SHOULD NOT effec=
t
s/effect/affect/ (the whole point of a file create request is to effect
file creation).
> transfered in it's entirity.
s/it's/its/
> If this field is present during a setstat operation, the file MUST b=
e
> extended or truncated to the specified size.
When a file is extended, is there any constraint on what appears in the
file between the old EOF point and the new? I'd prefer to see this
spelled out explicitly - it is for write requests.
> 7.4. allocation-size
> If this field is present during a setstat operation, the file SHOULD
> be extended or truncated to the specified size. The 'size' of the
> file may be affected by this operation. If the operation succeeds,
> the 'size' should be the minimum of the 'size' before the operation
> and the new 'allocation-size'.
(1) Again, what content appears when a file is extended?
(2) The last-quoted sentence above appears to forbid truncating a file,
in contrast to the first-quoted sentence; what am I missing?
> 7.6. Permissions
> This protocol uses the following values for the symbols declared in
> the POSIX standard.
> [...]
> Implementations MUST NOT send bits that are not defined.
This makes it impossible to send, for example, VMS "delete permission"
bits. Is this really desired, or is this being left up to
implementation experimentation before standardization?
> 7.9. attrib-bits and attrib-bits-valid
> This allows both the server and the client to
> communicate only the bits it knows about without inadvertently
> twiddling bits they don't understand.
s/bits it knows/bits they know/
> 8.1. Opening and Closing Files and Directories
> an opaque, variable-length string) which may be used to access the
I'd prefer s/,// here.
> 8.1.1.3. flags
> SSH_FXF_APPEND_DATA
> Data is always written at the end of the file. The offset field
> of the SSH_FXP_WRITE requests are ignored.
s/field/&s/ (or else s/are/is/). Also, maybe, s/the// on the second
line.
> SSH_FXF_BACKUP_STREAM
> However, if the server has a well
> defined backup stream format, their may be other uses for this
> data outside the scope of this protocol.
s/their/there/
> The following table is provided to assist in mapping POSIX semantics
> to equivalent SFTP file open parameters:
> O_RDONLY
I'd prefer to see a blank line after the colon, especially in view of
the blank lines between entries in the list.
> 8.2.1. Reading Files
> length
> If the server specified a non-zero 'max-read-size' in its
> 'supported2' (Section 5.4) extension, then failure to return
> 'length' bytes indicates that EOF or an error occurred.
Doesn't this apply only if length <=3D max-read-size?
> 8.3. Removing and Renaming Files
> If flags does not include SSH_FXP_RENAME_OVERWRITE, and there alread=
y
> exists a file with the name specified by newpath, the server MUST
> respond with SSH_FX_FILE_ALREADY_EXISTS.
What is correct behaviour when the server cannot avoid a race? For
example, I'm thinking of a Unix variant which renames directories only
with rename(), and there is no way to make rename() fail if the target
directory exists, is empty, and is writable by the calling user. Under
these conditions, there is no way for the server to correctly rename a
directory without RENAME_OVERWRITE, since there will always be a window
of time during which the target directory could have been created and
then overwritten in violation of the (lack of) the flag. Must servers
always fail renames they cannot implement correctly, or what? I notice
the lack of a paragraph indicating what the server is to do if it
cannot implement the rename as specified by this flag.
> 8.7. Dealing with Links
> The SSH_FXP_LINK request creates a link (either hard or symbolic) on
> the server.
> existing-path
> Specifies the path of an existing file system object to which the
> new-link-path will refer.
This makes it impossible to create a symlink pointing to something that
does not currently exist. This strikes me as an unreasonable
restriction.
> 8.8. Byte-range locks
> or advisory (meaning that no other process ca=
n
> obtain a conflicting lock, but the server does not enforce that no
> operation violates the lock.
Missing ) at end-of-sentence.
I see no mention of whether this same process can lock overlapping
ranges, and if so, how this interacts with unlocking (see below).
I see no mention of whether locks to end-of-file always extend to
end-of-file or whether they always extend to where end-of-file was when
the lockw as established, or whether either behaviour is permissible.
I see no mention of whether it is permitted to lock ranges that are not
currently part of the file, and whether such a lock means anything.
> Note that some server MAY return SSH_FX_OP_UNSUPPORTED if the
> handle is a directory handle.
s/server/&s/
> SSH_FXP_UNBLOCK removes a previously acquired byte-range lock on the
> specified handle.
There is no explicit mention of whether it is possible to unlock only
part of a previously-taken lock, or whether locks must be unlocked in
toto or not at all. There also is no indication of whether ranges
subject to multiple overlapping locks (if possible) must be unlocked
once per lock or whether the first unlock unlocks the range. Nor do I
see any indication of what happens in response to an attempt to unlock
a range not currently locked, or partially not currently locked.
> 9.1. Status Response
> Future protocol revisions will add additiona=
l
> error codes without changing the version number.
s/will/may/, unless I suppose you already have revisions in the
pipeline which will do that.
> SSH_FX_WRITE_PROTECT
> The file is on read-only media, or the media is write protected.
> SSH_FX_NO_MEDIA
> The requested operation cannot be completed because there is no
> media available in the drive.
"media" is plural (though the language seems to be unsure whether it is
a count noun or a mass noun). Thus, s/is/are/ where the referent is
"media" (the last "is" for each case), or s/media/medium/ for the
corresponding referent.
> SSH_FX_NO_SPACE_ON_FILESYSTEM
> The requested operation cannot be completed because there is no
> free space on the filesystem.
s/no/insufficient/, I would say.
> SSH_FX_LOCK_CONFLICT
> The file could not be opened because it is locked by another
> process.
This description makes this status inappropriate for SSH_FXP_BLOCK
requests that fail due to a lock conflict, which makes little sense to
me. s/file cound not be opened/request could not be performed/? Or
perhaps SSH_FX_BYTE_RANGE_LOCK_REFUSED should be returned for that?
The description of SSH_FXP_BLOCK doesn't say.
> SSH_FX_LINK_LOOP
> Too many symbolic links encountered.
While this wording is technically correct, I'd be inclined to add "or,
an SSH_FXF_NOFOLLOW open encountered a symbolic link as the final
component".
> SSH_FX_INVALID_PARAMETER
> On of the parameters was out of range, or the parameters specifie=
d
s/On/&e/
> 9.3. Data Response
> end-of-file
> This field is optional. If it is present in the packet, it MUST
> be true, and it indicates that EOF was reached during this read.
> This can help the client avoid a round trip to determine whether =
a
> short read was normal (due to EOF) or some other problem (limited
> server buffer for example.)
Is there any requirement that this be set when a read less than
max-read-size returns less than the requested length?
> 9.4. Name Response
> end-of-list
> If this field is present and true, there are no more entries to b=
e
> read.
The semantics of this field are unclear for NAME packets resulting from
things other than READDIR requests (READLINK and REALPATH, at present).
In passing, why is a false end-of-list permitted for NAME but not for
DATA?
> 12. IANA Considerations
> An IANA registry needs to be created containing:
> o The packet types define defined in Section 4.3
> o The extension specified in this draft, which are: [...]
Isn't that two registries?
> 13. Security Considerations
> It is assumed that both ends of the connection have been
> authenticated and that the connection has privacy and integrity
> features. Such security issues are left to the underlying transport
> protocol, except to note that if this is not the case, an attacker
> could manipulate files on the server at will and thus wholly
> compromise the server.
This was doing fine until the last six words. They do not necessarily
follow from the rest; it's not at all unreasonable to imagine some kind
of "anonymous sftp", akin to anonymous FTP, allowing unauthenticated
access to certain restricted areas, presumably rather restricted access
(eg, no writes). Such a thing need not allow "wholly compromis[ing]"
the server.
> particular user (the user being authenticated externally to this
> protocol, typically using [RFC4252].
Missing ) at end-of-sentence.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jul 10 17:49:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G03Ye-0007a6-Fx
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 10 Jul 2006 17:44:48 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G03LZ-0000IN-Oo
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 10 Jul 2006 17:31:18 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 4461A63B273; Mon, 10 Jul 2006 21:31:14 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from vandyke.com (mail.vandyke.com [216.184.10.33])
by mail.netbsd.org (Postfix) with ESMTP id 8FB3463B264
for ; Mon, 10 Jul 2006 21:31:11 +0000 (UTC)
Received: from [127.0.0.1] (HELO [0.0.0.0])
by vandyke.com (CommuniGate Pro SMTP 3.4.7)
with ESMTP id 9204477; Mon, 10 Jul 2006 15:31:10 -0600
Message-ID: <44B2C94F.4050707@vandyke.com>
Date: Mon, 10 Jul 2006 15:40:31 -0600
From: Joseph Galbraith
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: der Mouse
CC: ietf-ssh@NetBSD.org
Subject: Re: filexfer draft ready for last call?
References: <44AEEBAD.7040606@vandyke.com> <200607090528.BAA12682@Sparkle.Rodents.Montreal.QC.CA>
In-Reply-To: <200607090528.BAA12682@Sparkle.Rodents.Montreal.QC.CA>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 1.4 (+)
X-Scan-Signature: d67762704726a1bed57e7f4595960d34
der Mouse wrote:
>> I haven't really been doing much with the filexfer draft of late.
>
>> I'm not sure how far we'll get with a last call, but I'd kind of like
>> to start heading in that direction. So, if anyone has anything that
>> needs to be done, let's hear about it...
>
> What's the most recent? filexfer-12? That's the most recent I see on
> ftp.ietf.org.
>
> First, of course, it still has most of the same character-set issues it
> always did. If you don't want to even read about this again, skip the
> next two paragraphs.
>
> Section 6 tries to provide a nod in the direction of dealing with
> systems that don't do UTF-8, but it still demands that filenames be
> character sequences, which makes it unimplementable on systems (like
> traditional Unices) where filenames are octet sequences, with
> conversion to and from character sequences performed elsewhere if at
> all (usually by the display device and input device, and therefore (a)
> in a highly user- and often context-specific manner and (b) well beyond
> the power of the ssh/sftp implementation to detect). The draft
> suggests using LC_CTYPE, but gives no hints on how the implementation
> is supposed to detect what it is set to for the user in question - is
> it expected to include a parser for the user's shell startup files?
> (If indeed the user always uses the same LC_CTYPE, which may not be so.)
Our server reads a per-user option file (because we don't execute
shell scripts.)
I believe many unix servers _do_ execute the shell environment
files because they run the sftp subsystem in an separate process
under the shell.
> The simplest fix I see is to add a special charset-name for the
> filename-charset extension which means, basically, "raw octet
> sequences". (For concreteness, I suggest "RAW-8BIT".)
So you proposal is that we continue to require the server do
best effort translation to UTF-8 unless the client turns
this off; however, we allow the server to advertise that
what you are likely to get if you turn off is RAW-8BIT?
The only change being that we allow the server to
specify something that basically says I have no
clue about the char-set of the filenames.
I can live with that-- but it still seems more useful
to have the server give some guess as to the content.
> There is also a possible problem in that it appears to demand that
> files contain sequences of octets. This could be a problem for, for
> example, files (on, eg, a 36-bit machine) containing 9-bit bytes. I'm
> not sure this is worth fixing, given today's net.
I agree, I don't think this is worth addressing.
> Quite aside from that, there are some other issues, mostly but not
> entirely minor editorial fixes. Here are the ones I notice.
>
>> Abstract
>
>> The SSH File Transfer Protocol provides secure file transfer
>> functionality over any reliable data stream.
>
> s/data/octet/ here. (I'm assuming "flow-controlled" is subsumed into
> "reliable".) You might also add "bidirectional" for completeness.
Done and done.
>> This protocol provides secure file transfer (and more generally file
>> system access.)
>
> I would prefer to see the period outside the parens. I don't know
> whether this is just a mistake or whether you disagree philosophically
> on this point, though other sentences ending with parentheses imply the
> former.
Done.
>> It is designed so that it could be used to implement
>> a secure remote file system service, as well as a secure file
>> transfer service.
>
> s/,//
Done.
>> This protocol assumes that it runs over a secure channel, such as a
>> channel in [RFC4251], and that the server has already authenticated
>> the client, and that the identity of the client user is available to
>> the protocol.
>
> Strike the first "and".
Done.
>> This document owes it's initial creation and protocol design to Tatu
>> Ylonen and Sami Lehtinen of SSH Communications Security Corp.
>
> s/it's/its/
Done.
>> There are two packets, INIT and VERSION, which do not use the
>> request-id.
>> Packet descriptions in this document will contain the 'request-id'
>> field, but will not redefine it.
>
> I'd prefer to see a blank line in the middle here, or else these two
> sentences run together into a single paragraph.
Done.
>
>> In other words, only fields after the last
>> field the implementation wishes to send are actually options.
>
> s/options/optional/
Done.
>> 5.1. Client Initialization
>
>> If the client wishes
>> to interoperate with servers that support discontinuous version
>
> I'd prefer s/discontinuous/discontiguous/ (or perhaps noncontiguous).
Used noncontiguous.
>> 5.4. Supported Features
>
>> All servers MUST
>> include as part of their version packet.
>
> s/as/it as/
>
>> supported-attribute-mask
>> This mask MAY by applied to the 'File Attributes' valid-attribute-
>> flags field (Section 7.1) to ensure that no unsupported attributes
>> are present during a operation which writes attributes.
>
> s/by/be/
Done.
> Also, it's not clear whether this means "the client may want do this to
> make things easier on the server" or "the server is allowed to silently
> apply this mask".
I've changed it to be 'applied by the client.' Also, does the
discussion after the list make this any clearer?
>> supported-attribute-bits
>> This mask MAY by applied to the 'File Attributes' attrib-bits
>
> s/by/be/
Done.
>
>> case, the server is responsible for translating the clients
>
> s/clients/client's/
Done.
>> SSH_FXF_BLOCK_ADVISORY bits from Section 7.1.1.3, with a set bit
>
> There is no section 7.1.1.3. s/7/8/?
Done.
>> 7.1. valid-attribute-flags
>
>> New fields can only be added by incrementing the protocol version
>
> I'd prefer s/only be added/be added only/.
Done.
>> 7.3. Size
>
>> number of bytes the client intends to transfer, but SHOULD NOT effect
>
> s/effect/affect/ (the whole point of a file create request is to effect
> file creation).
Fixed.
>> transfered in it's entirity.
>
> s/it's/its/
Done.
>> If this field is present during a setstat operation, the file MUST be
>> extended or truncated to the specified size.
>
> When a file is extended, is there any constraint on what appears in the
> file between the old EOF point and the new? I'd prefer to see this
> spelled out explicitly - it is for write requests.
Done... identically to write requests.
>> 7.4. allocation-size
>
>> If this field is present during a setstat operation, the file SHOULD
>> be extended or truncated to the specified size. The 'size' of the
>> file may be affected by this operation. If the operation succeeds,
>> the 'size' should be the minimum of the 'size' before the operation
>> and the new 'allocation-size'.
I've reworked this section to avoid using 'extend' and 'truncate'
as this operation doesn't actually change the 'size' of the file
(unless the new 'allocation-size' is smaller.)
> (1) Again, what content appears when a file is extended?
In this case, the 'size' doesn't change; additional space
is reserved for the file, but the end-of-file isn't changed.
> (2) The last-quoted sentence above appears to forbid truncating a file,
> in contrast to the first-quoted sentence; what am I missing?
Ugh... fixed now.
>> 7.6. Permissions
>
>> This protocol uses the following values for the symbols declared in
>> the POSIX standard.
>
>> [...]
>
>> Implementations MUST NOT send bits that are not defined.
>
> This makes it impossible to send, for example, VMS "delete permission"
> bits. Is this really desired, or is this being left up to
> implementation experimentation before standardization?
But no one would know how to interpret those bits-- a client
including those bits to a server that expected posix modes
could / would cause problems. (And in fact we had a case
like this as AIX uses addition bits which we were sending
on the wire which caused problems when the server on a
non-aix system tried to set them.)
I'd be happy to add the VMS bits. I'd probably need at least
some rough description of what needs to be added (if I remember
correctly, doesn't VMS also have a SYSTEM field -- four fields
of four bits each?)
>> 7.9. attrib-bits and attrib-bits-valid
>
>> This allows both the server and the client to
>> communicate only the bits it knows about without inadvertently
>> twiddling bits they don't understand.
>
> s/bits it knows/bits they know/
Fixed.
>> 8.1. Opening and Closing Files and Directories
>
>> an opaque, variable-length string) which may be used to access the
>
> I'd prefer s/,// here.
Done.
>> 8.1.1.3. flags
>
>> SSH_FXF_APPEND_DATA
>> Data is always written at the end of the file. The offset field
>> of the SSH_FXP_WRITE requests are ignored.
>
> s/field/&s/ (or else s/are/is/). Also, maybe, s/the// on the second
> line.
Done.
>> SSH_FXF_BACKUP_STREAM
>
>> However, if the server has a well
>> defined backup stream format, their may be other uses for this
>> data outside the scope of this protocol.
>
> s/their/there/
Done.
>> The following table is provided to assist in mapping POSIX semantics
>> to equivalent SFTP file open parameters:
>> O_RDONLY
>
> I'd prefer to see a blank line after the colon, especially in view of
> the blank lines between entries in the list.
Done.
>> 8.2.1. Reading Files
>
>> length
>
>> If the server specified a non-zero 'max-read-size' in its
>> 'supported2' (Section 5.4) extension, then failure to return
>> 'length' bytes indicates that EOF or an error occurred.
>
> Doesn't this apply only if length <= max-read-size?
Fixed.
>> 8.3. Removing and Renaming Files
>
>> If flags does not include SSH_FXP_RENAME_OVERWRITE, and there already
>> exists a file with the name specified by newpath, the server MUST
>> respond with SSH_FX_FILE_ALREADY_EXISTS.
>
> What is correct behaviour when the server cannot avoid a race? For
> example, I'm thinking of a Unix variant which renames directories only
> with rename(), and there is no way to make rename() fail if the target
> directory exists, is empty, and is writable by the calling user. Under
> these conditions, there is no way for the server to correctly rename a
> directory without RENAME_OVERWRITE, since there will always be a window
> of time during which the target directory could have been created and
> then overwritten in violation of the (lack of) the flag. Must servers
> always fail renames they cannot implement correctly, or what? I notice
> the lack of a paragraph indicating what the server is to do if it
> cannot implement the rename as specified by this flag.
Clarified. 'SSH_FXP_RENAME_ATOMIC' specifies whether the client
needs the operation to be atomic, or whether a racey emulation is
acceptable.
>> 8.7. Dealing with Links
>
>> The SSH_FXP_LINK request creates a link (either hard or symbolic) on
>> the server.
>
>> existing-path
>> Specifies the path of an existing file system object to which the
>> new-link-path will refer.
>
> This makes it impossible to create a symlink pointing to something that
> does not currently exist. This strikes me as an unreasonable
> restriction.
Fixed.
>> 8.8. Byte-range locks
>
>> or advisory (meaning that no other process can
>> obtain a conflicting lock, but the server does not enforce that no
>> operation violates the lock.
>
> Missing ) at end-of-sentence.
Fixed.
> I see no mention of whether this same process can lock overlapping
> ranges, and if so, how this interacts with unlocking (see below).
Hmmm... well, my prefered answer is that
overlapping ranges are not allowed.
> I see no mention of whether locks to end-of-file always extend to
> end-of-file or whether they always extend to where end-of-file was when
> the lockw as established, or whether either behaviour is permissible.
I've clarified this as being 'current eof' -- the equivalent of
doing a SSH_FXP_STAT to retrieve the size and then issuing the
request based on that.
> I see no mention of whether it is permitted to lock ranges that are not
> currently part of the file, and whether such a lock means anything.
Clarified -- it is permissible to lock outside the file,
the same rules apply (i.e., if you block write access
to a range outside the file and someone else tries to
extend the file into that range, it should fail.)
>> Note that some server MAY return SSH_FX_OP_UNSUPPORTED if the
>> handle is a directory handle.
>
> s/server/&s/
Fixed.
>> SSH_FXP_UNBLOCK removes a previously acquired byte-range lock on the
>> specified handle.
>
> There is no explicit mention of whether it is possible to unlock only
> part of a previously-taken lock, or whether locks must be unlocked in
> toto or not at all.
Clarified.
There also is no indication of whether ranges
> subject to multiple overlapping locks (if possible) must be unlocked
> once per lock or whether the first unlock unlocks the range.
Not an issue due to no overlapping ranges (an excellent reason
to not do overlapping ranges :-)
Nor do I
> see any indication of what happens in response to an attempt to unlock
> a range not currently locked, or partially not currently locked.
Fixed.
>> 9.1. Status Response
>
>> Future protocol revisions will add additional
>> error codes without changing the version number.
>
> s/will/may/, unless I suppose you already have revisions in the
> pipeline which will do that.
Done.
>> SSH_FX_WRITE_PROTECT
>> The file is on read-only media, or the media is write protected.
>
>> SSH_FX_NO_MEDIA
>> The requested operation cannot be completed because there is no
>> media available in the drive.
>
> "media" is plural (though the language seems to be unsure whether it is
> a count noun or a mass noun). Thus, s/is/are/ where the referent is
> "media" (the last "is" for each case), or s/media/medium/ for the
> corresponding referent.
Uggh... there is no medium in the drive or are no media both
sound strange to me. Are you sure that 'media' isn't really
pretty much used as a singular noun in spite of what the
dictionary says?
>> SSH_FX_NO_SPACE_ON_FILESYSTEM
>> The requested operation cannot be completed because there is no
>> free space on the filesystem.
>
> s/no/insufficient/, I would say.
Done.
>> SSH_FX_LOCK_CONFLICT
>> The file could not be opened because it is locked by another
>> process.
>
> This description makes this status inappropriate for SSH_FXP_BLOCK
> requests that fail due to a lock conflict, which makes little sense to
> me. s/file cound not be opened/request could not be performed/? Or
> perhaps SSH_FX_BYTE_RANGE_LOCK_REFUSED should be returned for that?
> The description of SSH_FXP_BLOCK doesn't say.
Indeed, SSH_FXP_BLOCK does return SSH_FX_BYTE_RANGE_LOCK_REFUSED.
SSH_FX_LOCK_CONFLICT is returned from SSH_FXP_OPEN.
>> SSH_FX_LINK_LOOP
>> Too many symbolic links encountered.
>
> While this wording is technically correct, I'd be inclined to add "or,
> an SSH_FXF_NOFOLLOW open encountered a symbolic link as the final
> component".
Done.
>> SSH_FX_INVALID_PARAMETER
>> On of the parameters was out of range, or the parameters specified
>
> s/On/&e/
Fixed.
>> 9.3. Data Response
>
>> end-of-file
>> This field is optional. If it is present in the packet, it MUST
>> be true, and it indicates that EOF was reached during this read.
>> This can help the client avoid a round trip to determine whether a
>> short read was normal (due to EOF) or some other problem (limited
>> server buffer for example.)
>
> Is there any requirement that this be set when a read less than
> max-read-size returns less than the requested length?
No... it is still possible that the short read is not due to
EOF, but rather some other error (for example a bad media
sector.)
>> 9.4. Name Response
>
>> end-of-list
>> If this field is present and true, there are no more entries to be
>> read.
>
> The semantics of this field are unclear for NAME packets resulting from
> things other than READDIR requests (READLINK and REALPATH, at present).
Specified that the field should either be omitted or true for
requests other than SSH_FXP_READDIR.
> In passing, why is a false end-of-list permitted for NAME but not for
> DATA?
Someone pointed out that forcing it to have a certain value kind
of locked us in for future expansion of the packet in the NAME
case, but I didn't pick up on the same thing for data.
false is now permitted in both cases.
>> 12. IANA Considerations
>
>> An IANA registry needs to be created containing:
>> o The packet types define defined in Section 4.3
>> o The extension specified in this draft, which are: [...]
>
> Isn't that two registries?
Yes, I think you are correct.
>> 13. Security Considerations
>
>> It is assumed that both ends of the connection have been
>> authenticated and that the connection has privacy and integrity
>> features. Such security issues are left to the underlying transport
>> protocol, except to note that if this is not the case, an attacker
>> could manipulate files on the server at will and thus wholly
>> compromise the server.
>
> This was doing fine until the last six words. They do not necessarily
> follow from the rest; it's not at all unreasonable to imagine some kind
> of "anonymous sftp", akin to anonymous FTP, allowing unauthenticated
> access to certain restricted areas, presumably rather restricted access
> (eg, no writes). Such a thing need not allow "wholly compromis[ing]"
> the server.
I've changed it to read 'an attacker may be able to manipulate
files on the server and thus wholly compromise the server.'
Wholly compromising the server does pretty much follow
from manipulating files at will... in your example,
manipulating files at will isn't possible.
>> particular user (the user being authenticated externally to this
>> protocol, typically using [RFC4252].
>
> Missing ) at end-of-sentence.
Fixed.
Thanks for you feedback.
Joseph
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jul 11 01:32:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G0ArO-0001To-L3
for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 11 Jul 2006 01:32:38 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G0AiC-00027u-Q7
for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 11 Jul 2006 01:23:09 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 6E94963B2D2; Tue, 11 Jul 2006 05:23:05 +0000 (UTC)
X-Original-To: ietf-ssh@NetBSD.org
Delivered-To: ietf-ssh@NetBSD.org
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])
by mail.netbsd.org (Postfix) with ESMTP id CA1E763B154
for ; Tue, 11 Jul 2006 05:23:03 +0000 (UTC)
Received: from localhost (localhost [[UNIX: localhost]])
by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA16260;
Tue, 11 Jul 2006 01:23:03 -0400 (EDT)
From: der Mouse
Message-Id: <200607110523.BAA16260@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
Date: Tue, 11 Jul 2006 00:48:01 -0400 (EDT)
To: ietf-ssh@NetBSD.org
Subject: Re: filexfer draft ready for last call?
In-Reply-To: <44B2C94F.4050707@vandyke.com>
References: <44AEEBAD.7040606@vandyke.com> <200607090528.BAA12682@Sparkle.Rodents.Montreal.QC.CA>
<44B2C94F.4050707@vandyke.com>
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
>> First, of course, it still has most of the same character-set issues
>> it always did. [...]
>> The simplest fix I see is to add a special charset-name for the
>> filename-charset extension which means, basically, "raw octet
>> sequences". (For concreteness, I suggest "RAW-8BIT".)
> So you proposal is that we continue to require the server do best
> effort translation to UTF-8 unless the client turns this off;
> however, we allow the server to advertise that what you are likely to
> get if you turn off is RAW-8BIT?
Yes. Basically, a way for the server to say "my filenames are
charset-blind octet sequences; if you insist on UTF-8 you're likely to
get unpleasant surprises".
> The only change being that we allow the server to specify something
> that basically says I have no clue about the char-set of the
> filenames.
Right.
> I can live with that-- but it still seems more useful to have the
> server give some guess as to the content.
Possibly; it depends on whether you think a guess made with no
information behind it is more or less valuable than the information
that there is no information on which to base a guess. I can see it
going either way, depending on the context.
>>> supported-attribute-mask
>> Also, it's not clear whether this means "the client may want do this
>> to make things easier on the server" or "the server is allowed to
>> silently apply this mask".
> I've changed it to be 'applied by the client.' Also, does the
> discussion after the list make this any clearer?
Somewhat. I'm glad to see it clarified at the point of definition,
though.
>>> This protocol uses the following values for the symbols declared
>>> in the POSIX standard. [...]
>>> Implementations MUST NOT send bits that are not defined.
>> This makes it impossible to send, for example, VMS "delete
>> permission" bits. Is this really desired, or is this being left up
>> to implementation experimentation before standardization?
> But no one would know how to interpret those bits--
That depends. If the sftp spec says that these bits indicate delete
permission, then everyone knows what they mean, even if they might not
have any good local analog available.
In other respects, sftp seems to try to be a union of all the common
possibilities (eg, the way it handles locking); it seems odd for it to
take the opposite tack when it comes to permission bits.
> I'd be happy to add the VMS bits. I'd probably need at least some
> rough description of what needs to be added (if I remember correctly,
> doesn't VMS also have a SYSTEM field -- four fields of four bits
> each?)
That sounds right; it's been far too long since I used VMS, though, so
I'd have to go ask someone who still uses it, or dig up some docs.
>>> The file is on read-only media, or the media is write protected=
.
>>> [...] because there is no media available in the drive.
>> "media" is plural [...].
> Uggh... there is no medium in the drive or are no media both sound
> strange to me. Are you sure that 'media' isn't really pretty much
> used as a singular noun in spite of what the dictionary says?
Hmm. Actually, I think a good case could be made that it is becoming
(or perhaps even has become) a mass noun (at least when applied to
computer storage). And mass nouns usually act grammatically singular,
so you are probably right.
I usually try to reword the sentence to avoid depending on the number
of "media". In these cases, I'd perhaps try
The file is on read-only (or write-protected0 media.
...because the drive is empty.
On reflection, I now think that rewording is best, with leaving it the
way it was is second best. Switching to plural at least has historical
pedantry on its side, though it feels sufficiently odd to my modern eye
to relegate it to third place for me.
>> Or perhaps SSH_FX_BYTE_RANGE_LOCK_REFUSED should be returned for
>> [SSH_FXP_BLOCK conflicts]? The description of SSH_FXP_BLOCK doesn't
>> say.
> Indeed, SSH_FXP_BLOCK does return SSH_FX_BYTE_RANGE_LOCK_REFUSED.
> SSH_FX_LOCK_CONFLICT is returned from SSH_FXP_OPEN.
Just in case: I trust you made SSH_FXP_BLOCK call out which it uses?
> Wholly compromising the server does pretty much follow from
> manipulating files at will... in your example, manipulating files at
> will isn't possible.
Well, I suppose it's a matter of interpretation of what "at will"
means. I'm not about to lose any sleep over it, especially since to my
eye the rewording you gave fixes it.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jul 11 10:15:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G0J1M-0000Rw-A0
for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 11 Jul 2006 10:15:28 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G0J1K-00067i-Ug
for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 11 Jul 2006 10:15:28 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id E9F4163B2C4; Tue, 11 Jul 2006 14:15:23 +0000 (UTC)
X-Original-To: ietf-ssh@NetBSD.org
Delivered-To: ietf-ssh@NetBSD.org
Received: from beacon.PSC.process.com (beacon.psc.process.com [192.42.95.237])
by mail.netbsd.org (Postfix) with ESMTP id C37D063B114
for ; Tue, 11 Jul 2006 14:15:22 +0000 (UTC)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: filexfer draft ready for last call?
Date: Tue, 11 Jul 2006 09:11:18 -0400
Message-ID: <3EF96AF20489A34296050FBD5C36ECB93BD0D5@beacon.PSC.process.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: filexfer draft ready for last call?
Thread-Index: AcakaFgp9F3Gyyw4Sq258sanRW7sVwAgYLig
From: "Richard Whalen"
To: "Joseph Galbraith" ,
"der Mouse"
Cc:
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
> -----Original Message-----
> From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On
> Behalf Of Joseph Galbraith
> Sent: Monday, July 10, 2006 5:41 PM
> To: der Mouse
> Cc: ietf-ssh@NetBSD.org
> Subject: Re: filexfer draft ready for last call?
>=20
>=20
> der Mouse wrote:
:=20
> >> 7.6. Permissions
> >=20
> >> This protocol uses the following values for the symbols=20
> declared in
> >> the POSIX standard.
> >=20
> >> [...]
> >=20
> >> Implementations MUST NOT send bits that are not defined.
> >=20
> > This makes it impossible to send, for example, VMS "delete=20
> permission"
> > bits. Is this really desired, or is this being left up to
> > implementation experimentation before standardization?
>=20
> But no one would know how to interpret those bits-- a client
> including those bits to a server that expected posix modes
> could / would cause problems. (And in fact we had a case
> like this as AIX uses addition bits which we were sending
> on the wire which caused problems when the server on a
> non-aix system tried to set them.)
>=20
> I'd be happy to add the VMS bits. I'd probably need at least
> some rough description of what needs to be added (if I remember
> correctly, doesn't VMS also have a SYSTEM field -- four fields
> of four bits each?)
>
VMS has four groups of four bits: System, Owner, Group and World
and the bits defined Read, Write, Execute and Delete permission.
VMS Execute permission is different from Unix eXecute permission;
VMS Execute permission can be considered to be a subset of Read,
because it allows a program to be loaded into memory and run.=20
It also allows a command file to be run, or lookup of a specific
file in a directory.
As for implementations sending attributes other than what are
defined, there are always the private extended attributes. There
are no rules stated as which should take precedence when there
are conflicts between the defined attributes and private extended
attributes, but I think that a safe assumption would be that an
implementation that uses private extended attributes would be
using them to communicate more file information than can be done
via the attributes that are defined by the specification and hence
private extended attributes should supercede defined attributes.
In general I would expect few actual conflicts as the defined
attributes would be derived from the actual attributes of the
file.
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Jul 13 03:13:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G0vOB-0006GR-Ks
for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 13 Jul 2006 03:13:35 -0400
Received: from mail.netbsd.org ([204.152.190.11])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G0vOA-0002pn-BT
for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 13 Jul 2006 03:13:35 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 7766A63B1AA; Thu, 13 Jul 2006 07:13:27 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from csegrad.ucsd.edu (csegrad.ucsd.edu [132.239.55.5])
by mail.netbsd.org (Postfix) with ESMTP id B104463B156
for ; Thu, 13 Jul 2006 07:13:26 +0000 (UTC)
Received: from localhost.localdomain (localhost [127.0.0.1])
by csegrad.ucsd.edu (8.13.1/8.13.1) with ESMTP id k6D7DQ4W003095
for ; Thu, 13 Jul 2006 00:13:26 -0700
Message-Id: <200607130713.k6D7DQ4W003095@csegrad.ucsd.edu>
To: ietf-ssh@netbsd.org
From: tkohno@cs.ucsd.edu (Tadayoshi Kohno)
Date: Thu, 13 Jul 2006 00:13:26 -0700
Subject: Re: Fw: SeX.mpg [Auto reply]
X-Spam-Status: No, score=0.0 required=5.0 autolearn=failed version=3.0.6
scanner=csegrad.ucsd.edu
X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on csegrad.ucsd.edu
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d62ab47271805379d7172ee693a45db
I am away and will reply to your email regarding "Fw: SeX.mpg" as soon as possible.
Thank you very much,
Yoshi
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Jul 15 14:35:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G1ozL-0006Pk-48
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 15 Jul 2006 14:35:39 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G1ozJ-0001nj-SB
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 15 Jul 2006 14:35:39 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id CF3D763B1FB; Sat, 15 Jul 2006 18:35:34 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102])
by mail.netbsd.org (Postfix) with ESMTP id 262ED63B11B
for ; Sat, 15 Jul 2006 18:35:34 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by mail.siliconcircus.com (Postfix) with ESMTP id 674E5FFD0F
for ; Sat, 15 Jul 2006 18:38:09 +0200 (CEST)
Message-ID: <44B919F2.4080507@siliconcircus.com>
Date: Sat, 15 Jul 2006 18:38:10 +0200
From: Jon Bright
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: ietf-ssh@netbsd.org
Subject: Publickey Subsystem seems to have got lost
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Hi,
The publickey subsystem draft has been through the RFC editor and a WG
last call which didn't turn up any substantive issues. Nonetheless,
it's not been published as an RFC and the most recent draft has now
expired.
What needs to be done to push it towards getting published?
--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jul 18 16:50:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G2wWJ-0005M2-VT
for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Jul 2006 16:50:19 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G2wWI-0005LO-L6
for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 18 Jul 2006 16:50:19 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 3A26863B16E; Tue, 18 Jul 2006 20:50:15 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
by mail.netbsd.org (Postfix) with ESMTP id 398BB63B128
for ; Tue, 18 Jul 2006 20:50:14 +0000 (UTC)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6IJo2MN027987
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Tue, 18 Jul 2006 19:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
id 1G2vZx-0000kA-Vr; Tue, 18 Jul 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: ietf-ssh@netbsd.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-filexfer-13.txt
Message-Id:
Date: Tue, 18 Jul 2006 15:50:01 -0400
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.3 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.
Title : SSH File Transfer Protocol
Author(s) : J. Galbraith, O. Saarenmaa
Filename : draft-ietf-secsh-filexfer-13.txt
Pages : 60
Date : 2006-7-18
The SSH File Transfer Protocol provides secure file transfer
functionality over any reliable, bidirectional octect stream. It is
the standard file transfer protocol for use with the SSH2 protocol.
This document describes the file transfer protocol and its interface
to the SSH2 protocol suite.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-13.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-secsh-filexfer-13.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-secsh-filexfer-13.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2006-7-18124309.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-filexfer-13.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-secsh-filexfer-13.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2006-7-18124309.I-D@ietf.org>
--OtherAccess--
--NextPart--
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jul 21 11:18:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G3wlW-0001ud-Jb
for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 21 Jul 2006 11:18:10 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G3wdF-0004Ng-Is
for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 21 Jul 2006 11:09:40 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 3874C63B283; Fri, 21 Jul 2006 15:09:34 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from opentech.lzu.edu.cn (unknown [IPv6:2001:da8:c000:1101:2d0:b7ff:feb7:f2df])
by mail.netbsd.org (Postfix) with ESMTP id B92FC63B12B
for ; Fri, 21 Jul 2006 15:09:31 +0000 (UTC)
Received: from opentech.lzu.edu.cn (opentech.lzu.edu.cn [202.38.127.182])
by opentech.lzu.edu.cn (8.13.1/8.13.1) with ESMTP id k6LEewvZ007808;
Fri, 21 Jul 2006 22:40:58 +0800
Date: Fri, 21 Jul 2006 22:40:58 +0800
Message-Id: <200607211440.k6LEewvZ007808@opentech.lzu.edu.cn>
To: nag@nag.ru, Sales@kleinhenz.com, wirzd@gmx.net, mogul@su-shasta.arpa,
davy@purdue-ecn.ARPA, tom@LOGICON.ARPA, cain@EDN-UNIX.ARPA,
gross@mitre.ARPA, wieland@unitedvisions.tv, phpsensors@antitachyon.com,
michael@seso.ch, goo@wnet.ua, zavolzhsky@mail.ru,
info@gs-uvek.admin.ch, ietf-ssh@netbsd.org,
openssh-unix-announce@mindrot.org, openssh-unix-dev@mindrot.org,
secureshell@securityfocus.com, secureshell-subscribe@securityfocus.com,
secureshell-unsubscribe@securityfocus.com,
agk@hyperion.CS.berkeley.edu, bjorn@hyperion.CS.berkeley.edu,
phil@decwrl.DEC.COM, andreas@zemp.it, openssh@openssh.com,
djm@openbsd.org, oF@q.0l, rek@ct.heise.de,
anoncvs@openbsd.informatik.uni-erlangen.de, grunk@pestilenz.org,
anoncvs@obsd.isc.org, millert@openbsd.org, anoncvs@plier.ucar.edu
From: mcguire@lzu.edu.cn
Subject: [RTLWS8-CFP] Eighth Real-Time Linux Workshop 2nd CFP
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: -2.6 (--)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
We apologize for multiple receipts.
--------------------------------------------------------------------------------
Eighth Real-Time Linux Workshop
October 12-15, 2006
Lanzhou University - SISE
Tianshui South Road 222
Lanzhou, Gansu 730000
P.R.China
General
Following the meetings of developers and users at the previous 7
successful real-time Linux workshops held in Vienna, Orlando, Milano,
Boston, and Valencia, Singapore, Lille, the Real-Time Linux Workshop
for 2006 will come back to Asia again, to be held at the School for
Information Science and Engineering, Lanzhou University, in Lanzhou
China.
Embedded and real-time Linux is rapidly gaining traction in the Asia
Pacific region. Embedded systems in both automation/control and
entertainment moving to 32/64bit systems, opening the door for the use
of full featured OS like GNU/Linux on COTS based systems. With
real-time capabilities being a common demand for embedded systems the
soft and hard real-time variants are an important extension to the
versatile GNU/Linux GPOS.
Authors are invited to submit original work dealing with general
topics related to real-time Linux research, experiments and case
studies, as well as issues of integration of real-time and embedded
Linux. A special focus will be on industrial case studies. Topics of
interest include, but are not limited to:
* Modifications and variants of the GNU/Linux operating system
extending its real-time capabilities,
* Contributions to real-time Linux variants, drivers and extensions,
* User-mode real-time concepts, implementation and experience,
* Real-time Linux applications, in academia, research and industry,
* Work in progress reports, covering recent developments,
* Educational material on real-time Linux,
* Tools for embedding Linux or real-time Linux and embedded
real-time Linux applications,
* RTOS core concepts, RT-safe synchronization mechanisms,
* RT-safe interaction of RT and non RT components,
* IPC mechanisms in RTOS,
* Analysis and Benchmarking methods and results of
real-time GNU/Linux variants,
* Debugging techniques and tools, both for code and temporal
debugging of core RTOS components, drivers and real-time
applications,
* Real-time related extensions to development environments.
Further information:
EN: http://www.realtimelinuxfoundation.org/events/rtlws-2006/ws.html
CN: http://dslab.lzu.edu.cn/rtlws8/index.html
Awarded papers
The Programme Committee will award a best paper in the category Real-
Time Systems Theory. This best paper will be invited for publication
to the Real-Time Systems Journal, RTSJ.
The Programme Committee will award a best paper in the category Real-
Time Systems Application. This best paper will be invited for publication
to the Dr Dobbs Journal. Moreover, the publication of the other papers in
a special issue of Dr Dobbs Journal is in discussion.
Abstract submission
In order register an abstract, please go to:
http://www.realtimelinuxfoundation.org/rtlf/register-abstract.html
Venue
Lanzhou University Information Building, School of Information Science
and Engineering, Laznhou University, http://www.lzu.edu.cn/.
Registration
In order to participate to the workshop, please register on the
registration page at:
http://www.realtimelinuxfoundation.org/rtlf/register-participant.html
Accommodation
Please refer to the Lanzhou hotel page for accomodation at
http://dslab.lzu.edu.cn/rtlws8/hotels/hotels.htm
Travel information
For travel information and directions how to get to Lanzhou from an
international airport in China please refer to:
http://www.realtimelinuxfoundation.org/events/rtlws-2006/
Important dates
August 28: Abstract submission
September 15: Notification of acceptance
September 29: Final paper
Pannel Participants:
o Roberto Bucher - Scuola Universitaria Professionale della Svizzera
Italiana, Switzerland, RTAI/ADEOS/RTAI-Lab.
o Alfons Crespo Lorente - University of Valenica, Spain,Departament
d'Informtica de Sistemes i Computadors, XtratuM.
o Herman Haertig - Technical University Dresden, Germany,Institute for
System Architecture, L4/Fiasco/L4Linux.
o Nicholas Mc Guire - Lanzhou University, P.R. China, Distributed and
Embedded Systems Lab, RTLinux/GPL.
o Douglas Niehaus - University of Kansas, USA, Information and
Telecommunication Technology Center, RT-preempt.
Organization committee:
* Prof. Li LIAN (Co-Chair), (SISE, Lanzhou University, CHINA)
* Xiaoping ZHANG, LZU, CHINA
* Jiming WANG, PKU, CHINA
* Zhibing LI, ECNU, China
* Prof. Nicholas MCGUIRE (Co-Chair), Real Time Linux Foundation
(RTLF)
* Dr. Peter WURMSDOBLER, Real Time Linux Foundation (RTLF)
* Dr. Qingguo ZHOU, (Distributed and Embedded Systems Lab, Lanzhou
University, CHINA)
Program committee:
* Prof. Li Xing (Co-Chair), (Tsinghua University, CHINA)
* Dr. Zhang Yunquan, (Institute of Software, Chinese Academy of
Science, CHINA)
* Dr. Chen Yu, (Tsinghua University, CHINA)
* Dr. Chen Maoke, (Tsinghua University, CHINA)
* Dr. Yu Guanghui, (Dalian University of Techonolgy, CHINA)
* Prof. Dr. Paolo Mantegazza, (Dipartimento di Ingegneria
Aerospaziale, ITALY)
* Prof. Dr. Bernhard Zagar, (Johannes Kepler Universitt Linz,
AUSTRIA)
* Prof. Dr. Hermann Hrtig, (Technische Universitt Dresden,
Fakultt Informatik, GERMANY)
* Prof. Tei-Wei Kuo, (National Taiwan University, Department of
Computer Science and Information Engineering,TAIWAN)
* Anthony Skjellum, (Mississippi State University, USA)
* Ing. Pavel Pisa, (Czech Technical University, CZECH REPUBLIC)
* Prof. Alfons Crespo, (Universidad Politcnica de Valencia, SPAIN)
* Dr. Qingguo Zhou, (Lanzhou University, CHINA)
* PhD. Jaesoon Choi, (National Cancer Center, KOREA)
* Prof. Douglas Niehaus, (Kansas University, USA)
* Dr. Michael Hohmuth, (Technische Universitt Dresden, GERMANY)
* Prof. Thambipillai Srikanthan, (Nanyang Technological University,
SINGAPORE)
* Zhengting He, (University of Texas, USA)
* Martin Terbuc, (Universitz of Maribor, SLOVENIA)
* Yoshinori Sato, (the H8/300 project, JAPAN)
* Yuqing Lan, (China Standard SoftwareCo.,LTD, CHINA)
* Dr. Peter Wurmsdobler, (Real Time Linux Foundation, USA)
* Prof. Nicholas Mc Guire (Co-Chair), (Lanzhou University, CHINA)
Workshop organizers:
* School for Information Science and Engineering (SISE) , Lanzhou
University , CHINA
* IBM China, Xi'an Branch , China
* Haag Embedded Systems, Austira
Peter Wurmsdobler
Nicholas Mc Guire
Zhou Qingguo
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jul 21 17:51:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G42uX-0004L1-1g
for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 21 Jul 2006 17:51:53 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G42uU-0006fe-Fc
for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 21 Jul 2006 17:51:53 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 6E27C63B103; Fri, 21 Jul 2006 21:51:47 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from web34302.mail.mud.yahoo.com (web34302.mail.mud.yahoo.com [66.163.178.134])
by mail.netbsd.org (Postfix) with SMTP id 459CD63B142
for ; Fri, 21 Jul 2006 21:51:46 +0000 (UTC)
Received: (qmail 87243 invoked by uid 60001); 21 Jul 2006 20:05:05 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com.ar;
h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
b=L45+seIolAYAbPvtBONf/9bpvYm6iQ5y7SK/zWuV2niOmanU7ewV6kByxUhFKIJ0/+KwidoMWJMS7QHdPUvVHiVt0f02CVAtgDjFxcQkcZA6eJr6IAow5yEpoBIvdxHQiXmTpZXhsZXLbMGpmjon3ut2D49JmS7NBTDSsgYLfWA= ;
Message-ID: <20060721200505.87241.qmail@web34302.mail.mud.yahoo.com>
Received: from [201.198.239.67] by web34302.mail.mud.yahoo.com via HTTP; Fri, 21 Jul 2006 20:05:05 GMT
Date: Fri, 21 Jul 2006 20:05:05 +0000 (GMT)
From: Noel Keith
Subject: SSH server Radius server
To: ietf-ssh@netbsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Hello All:
I=B4d like to know if i=B4d use to access remote
(athentication and authorization ) for to Management
Network a Radius server with ssh.
But i don=B4t know if i must to have two servers, like;
Radius Server
SSH Server
Other question if i use ssh with Radius i must to use
CHAP ?
Cheers,
N.K.
=09
=09
=09
__________________________________________________
Pregunt=E1. Respond=E9. Descubr=ED.
Todo lo que quer=EDas saber, y lo que ni imaginabas,
est=E1 en Yahoo! Respuestas (Beta).
=A1Probalo ya!=20
http://www.yahoo.com.ar/respuestas
From test1@mail.tour2000.co.kr Mon Jul 24 17:48:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G58Hq-0006ly-Fv
for secsh-archive@megatron.ietf.org; Mon, 24 Jul 2006 17:48:26 -0400
Received: from [210.92.25.4] (helo=mail.tour2000.co.kr)
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G58Ho-0003zd-0P
for secsh-archive@megatron.ietf.org; Mon, 24 Jul 2006 17:48:26 -0400
Received: from mail.tour2000.co.kr (localhost.localdomain [127.0.0.1])
by mail.tour2000.co.kr (8.13.1/8.13.1) with ESMTP id k6OLtMBB031329
for ; Tue, 25 Jul 2006 06:55:22 +0900
Received: (from test1@localhost)
by mail.tour2000.co.kr (8.13.1/8.13.1/Submit) id k6OLtLop031328;
Tue, 25 Jul 2006 06:55:21 +0900
Date: Tue, 25 Jul 2006 06:55:21 +0900
Message-Id: <200607242155.k6OLtLop031328@mail.tour2000.co.kr>
To: secsh-archive@megatron.ietf.org
Subject: Message from eBay Member
From: eBay-Mitglied gret
Content-Type: text/html
X-Spam-Score: 1.9 (+)
X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79
eBay sent this message. Your registered name
is included to show this message originated from eBay. Learn
more. | |
|
Question from eBay Member --
Respond Now |
|
|
eBay sent this message on
behalf of an eBay member via My Messages. Responses sent
using email will not reach the eBay member. Use the
Respond Now button below to respond to this
message. | |
| | |
|
|
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Jul 29 20:29:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G6zBA-0004d9-KT
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 29 Jul 2006 20:29:12 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G6zB9-0003K8-BX
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 29 Jul 2006 20:29:12 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 1CBD263B319; Sun, 30 Jul 2006 00:29:08 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178])
by mail.netbsd.org (Postfix) with ESMTP id 3627763B318
for ; Sun, 30 Jul 2006 00:29:07 +0000 (UTC)
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
id BAD89E00C1; Sat, 29 Jul 2006 19:15:10 -0400 (EDT)
From: Sam Hartman
To: ietf-ssh@netbsd.org
Cc: housley@vigilsec.com
Subject: Formal consultation prior to closing the secsh working group
Date: Sat, 29 Jul 2006 19:15:10 -0400
Message-ID:
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Hi folks.
The ssh working group has accomplished its primary objective and has
published the core protocol as RFCs. We've also published several
related extensions.
We have not managed to publish the filexfer, URI or X.509 drafts.
However, I've come to the conclusion that there is insufficient energy
in this working group to continue reviewing or producing documents.
All of our milestones are from 2005. There seems to be no significant
activity on anything other than the filexfer draft.
I'm very concerned about the filexfer draft. It is well on the way to
becoming a filesystem, not just an ftp-like protocol. I am concerned
that we don't have enough reviewers to manage the complexity of the
draft and to force us to make hard decisions about what features we
really need. Instead, we're close to including everything. I have
received several private comments to this effect. I am not sure that
we have the skill set necessary to design and review a filesystem
document and I think that is what filexfer is becoming.
RFC 2418 defines procedures for creating, managing and terminating of
working groups. That document stresses the importance of an active
community of reviewers and subject matter experts. IT makes it clear
that it is the responsibility of the working group to make sure the
right people are available to do the work of the WG.
I no longer think this working group has sufficient reviewers or
contributors. So, I propose to close the working group.
RFC 2418 requires a formal consultation prior to closing a working
group. This message serves as the beginning of such a consultation.
I'd like to solicit comments on the proposal to close the secsh
working group by August 14, 2006.
Thanks,
Sam Hartman
Security Area Director
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Jul 29 22:08:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G70j1-0002Y7-Vj
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 29 Jul 2006 22:08:15 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G70iy-0001JV-LX
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sat, 29 Jul 2006 22:08:15 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 04ADD63B198; Sun, 30 Jul 2006 02:08:10 +0000 (UTC)
X-Original-To: ietf-ssh@NetBSD.org
Delivered-To: ietf-ssh@NetBSD.org
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])
by mail.netbsd.org (Postfix) with ESMTP id A8FC663B111
for ; Sun, 30 Jul 2006 02:08:08 +0000 (UTC)
Received: (from mouse@localhost)
by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id WAA02290;
Sat, 29 Jul 2006 22:08:07 -0400 (EDT)
From: der Mouse
Message-Id: <200607300208.WAA02290@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
Date: Sat, 29 Jul 2006 22:04:38 -0400 (EDT)
To: ietf-ssh@NetBSD.org
Subject: Re: Formal consultation prior to closing the secsh working group
In-Reply-To:
References:
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
> However, I've come to the conclusion that there is insufficient
> energy in this working group to continue reviewing or producing
> documents.
Well spotted. I think I agree.
> I'm very concerned about the filexfer draft. It is well on the way
> to becoming a filesystem, not just an ftp-like protocol.
Agreed. I thought we had decided that was what we wanted (for values
of "we" that care enough to speak up, at least).
> I am concerned that we don't have enough reviewers to manage the
> complexity of the draft and to force us to make hard decisions about
> what features we really need.
Such decisions are hard only if we don't want a remote filesystem
access protocol instead of just a file transfer protocol.
> I no longer think this working group has sufficient reviewers or
> contributors. So, I propose to close the working group.
Little as I like it, I am forced to agree. Would this necessarily
involve shutting down the mailing list? I can see it still serving a
useful function discussing implementations and interpretation issues.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Jul 30 16:34:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G7HzQ-0007PH-8z
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 30 Jul 2006 16:34:20 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G7HzO-0004Wr-Uq
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 30 Jul 2006 16:34:20 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 4D04663B163; Sun, 30 Jul 2006 20:34:11 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32])
by mail.netbsd.org (Postfix) with ESMTP id 28DD863B36B
for ; Sun, 30 Jul 2006 20:34:09 +0000 (UTC)
Received: from pc6 (1Cust34.tnt101.lnd4.gbr.da.uu.net [213.116.50.34])
by ranger.systems.pipex.net (Postfix) with SMTP id 0A3EAE0003C4;
Sun, 30 Jul 2006 21:34:06 +0100 (BST)
Message-ID: <00cb01c6b40e$73bc4d20$0601a8c0@pc6>
Reply-To: "tom.petch"
From: "tom.petch"
To: "Sam Hartman" ,
Cc:
References:
Subject: Re: Formal consultation prior to closing the secsh working group
Date: Sun, 30 Jul 2006 21:29:11 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Yes, sadly, I too think that the energy in this group has subsided to the point
where further progress on I-Ds is unlikely to be timely or reviewed in depth.
My concern is that the use of ssh is still growing - isms being an obvious one,
syslog over ssh less so - and, like tls, people with an applications background
struggling to write I-Ds need help from those better versed in security matters.
Currenlty, the ssh and tls lists serve that purpose. As and when ssh closes,
where should such a discussion go? Leaving the list open is an option but my
experience is that the support for it withers away. Is there a better home for
ongoing support?
Tom Petch
----- Original Message -----
From: "Sam Hartman"
To:
Cc:
Sent: Sunday, July 30, 2006 1:15 AM
Subject: Formal consultation prior to closing the secsh working group
>
>
> Hi folks.
>
> The ssh working group has accomplished its primary objective and has
> published the core protocol as RFCs. We've also published several
> related extensions.
>
> We have not managed to publish the filexfer, URI or X.509 drafts.
>
> However, I've come to the conclusion that there is insufficient energy
> in this working group to continue reviewing or producing documents.
> All of our milestones are from 2005. There seems to be no significant
> activity on anything other than the filexfer draft.
>
> I'm very concerned about the filexfer draft. It is well on the way to
> becoming a filesystem, not just an ftp-like protocol. I am concerned
> that we don't have enough reviewers to manage the complexity of the
> draft and to force us to make hard decisions about what features we
> really need. Instead, we're close to including everything. I have
> received several private comments to this effect. I am not sure that
> we have the skill set necessary to design and review a filesystem
> document and I think that is what filexfer is becoming.
>
>
> RFC 2418 defines procedures for creating, managing and terminating of
> working groups. That document stresses the importance of an active
> community of reviewers and subject matter experts. IT makes it clear
> that it is the responsibility of the working group to make sure the
> right people are available to do the work of the WG.
>
> I no longer think this working group has sufficient reviewers or
> contributors. So, I propose to close the working group.
>
> RFC 2418 requires a formal consultation prior to closing a working
> group. This message serves as the beginning of such a consultation.
> I'd like to solicit comments on the proposal to close the secsh
> working group by August 14, 2006.
>
>
> Thanks,
>
> Sam Hartman
> Security Area Director
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Jul 30 16:39:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G7I4i-0004uj-1l
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 30 Jul 2006 16:39:48 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G7I4g-0005H0-QA
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 30 Jul 2006 16:39:48 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 8EACC63B2BB; Sun, 30 Jul 2006 20:39:45 +0000 (UTC)
X-Original-To: ietf-ssh@NetBSD.org
Delivered-To: ietf-ssh@NetBSD.org
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178])
by mail.netbsd.org (Postfix) with ESMTP id BE0D163B16C
for ; Sun, 30 Jul 2006 20:39:44 +0000 (UTC)
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
id 11F3EE00C1; Sun, 30 Jul 2006 16:40:33 -0400 (EDT)
From: Sam Hartman
To: der Mouse
Cc: ietf-ssh@NetBSD.org
Subject: Re: Formal consultation prior to closing the secsh working group
References:
<200607300208.WAA02290@Sparkle.Rodents.Montreal.QC.CA>
Date: Sun, 30 Jul 2006 16:40:33 -0400
In-Reply-To: <200607300208.WAA02290@Sparkle.Rodents.Montreal.QC.CA> (der
Mouse's message of "Sat, 29 Jul 2006 22:04:38 -0400 (EDT)")
Message-ID:
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
>>>>> "der" == der Mouse writes:
der> Little as I like it, I am forced to agree. Would this
der> necessarily involve shutting down the mailing list? I can
der> see it still serving a useful function discussing
der> implementations and interpretation issues.
I would strongly prefer the mailing list stay around. Typically we
try and keep at least one mailing list alive for a technology
especially once rfcs are published. You need it to see if you have
interest in forming related working groups in the future, discussion
of bugs in the standards, etc, etc. You also tend to find the mailing
list useful to advance standards, which does not require a WG.
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Jul 30 17:22:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G7Ijf-0002yR-Ii
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 30 Jul 2006 17:22:07 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G7Ije-0006Ms-Ag
for secsh-tyoxbijeg7-archive@lists.ietf.org; Sun, 30 Jul 2006 17:22:07 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 5DF8F63B37E; Sun, 30 Jul 2006 21:22:04 +0000 (UTC)
X-Original-To: ietf-ssh@NetBSD.org
Delivered-To: ietf-ssh@NetBSD.org
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])
by mail.netbsd.org (Postfix) with ESMTP id 2951A63B371
for ; Sun, 30 Jul 2006 21:22:02 +0000 (UTC)
Received: (from mouse@localhost)
by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA00893;
Sun, 30 Jul 2006 17:22:01 -0400 (EDT)
From: der Mouse
Message-Id: <200607302122.RAA00893@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
Date: Sun, 30 Jul 2006 17:19:57 -0400 (EDT)
To: ietf-ssh@NetBSD.org
Subject: Re: Formal consultation prior to closing the secsh working group
In-Reply-To:
References:
<200607300208.WAA02290@Sparkle.Rodents.Montreal.QC.CA>
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
>> Little as I like it, I am forced to agree [that the secsh WG seems
>> pretty much dead]. Would [shutting it down] necessarily involve
>> shutting down the mailing list?
> I would strongly prefer the mailing list stay around.
In case it wasn't clear from my message (mostly bits that I cut when
trimming for this mail), I totally agree with you there.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jul 31 03:24:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G7S8x-0004UC-L1
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 03:24:51 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G7S8t-0001M0-8f
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 03:24:51 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 5043363B1B3; Mon, 31 Jul 2006 07:24:44 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102])
by mail.netbsd.org (Postfix) with ESMTP id F3A8B63B115
for ; Mon, 31 Jul 2006 07:24:42 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by mail.siliconcircus.com (Postfix) with ESMTP id 7CCA8102536;
Mon, 31 Jul 2006 09:24:35 +0200 (CEST)
Message-ID: <44CDB12F.30106@siliconcircus.com>
Date: Mon, 31 Jul 2006 09:28:47 +0200
From: Jon Bright
Organization: Silicon Circus Ltd.
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Sam Hartman
CC: ietf-ssh@netbsd.org, housley@vigilsec.com
Subject: Re: Formal consultation prior to closing the secsh working group
References:
In-Reply-To:
Content-Type: multipart/mixed;
boundary="------------010305020903040600090604"
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
This is a multi-part message in MIME format.
--------------010305020903040600090604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
Sam Hartman wrote:
>
> The ssh working group has accomplished its primary objective and has
> published the core protocol as RFCs. We've also published several
> related extensions.
Whilst I'm in agreement with regard to your mail, I would like to get my
shepherding of the Publickey Subsystem finished before the WG goes away.
It's been through last call here, it's been to the RFC editor, it just
hasn't been published. I've attached my message from 15th July.
Perhaps you can give me a pointer about what I need to do to get it
published?
I'm also of the opinion that the ML should stay.
--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com
--------------010305020903040600090604
Content-Type: message/rfc822;
name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Attached Message"
Return-Path:
X-Original-To: sircus@mail.siliconcircus.com
Delivered-To: sircus@mail.siliconcircus.com
Received: by mail.siliconcircus.com (Postfix, from userid 1001)
id 936E1FFE8E; Sat, 15 Jul 2006 20:35:48 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
drno.siliconcircus.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.1.1
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by mail.siliconcircus.com (Postfix) with ESMTP id 3FAB5F5B53
for ; Sat, 15 Jul 2006 20:35:42 +0200 (CEST)
Received: by mail.netbsd.org (Postfix, from userid 0)
id CF3D763B1FB; Sat, 15 Jul 2006 18:35:34 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102])
by mail.netbsd.org (Postfix) with ESMTP id 262ED63B11B
for ; Sat, 15 Jul 2006 18:35:34 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by mail.siliconcircus.com (Postfix) with ESMTP id 674E5FFD0F
for ; Sat, 15 Jul 2006 18:38:09 +0200 (CEST)
Message-ID: <44B919F2.4080507@siliconcircus.com>
Date: Sat, 15 Jul 2006 18:38:10 +0200
From: Jon Bright
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: ietf-ssh@netbsd.org
Subject: Publickey Subsystem seems to have got lost
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
Hi,
The publickey subsystem draft has been through the RFC editor and a WG
last call which didn't turn up any substantive issues. Nonetheless,
it's not been published as an RFC and the most recent draft has now
expired.
What needs to be done to push it towards getting published?
--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com
--------------010305020903040600090604--
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jul 31 09:15:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G7Xc0-0004hi-AA
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 09:15:12 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G7Xbz-0007G1-10
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 09:15:12 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 69A2A63B3E9; Mon, 31 Jul 2006 13:15:08 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from beacon.PSC.process.com (beacon.psc.process.com [192.42.95.237])
by mail.netbsd.org (Postfix) with ESMTP id 74CCE63B113
for ; Mon, 31 Jul 2006 13:15:07 +0000 (UTC)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Formal consultation prior to closing the secsh working group
X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Mon, 31 Jul 2006 09:16:38 -0400
Message-ID: <3EF96AF20489A34296050FBD5C36ECB93BD140@beacon.PSC.process.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Formal consultation prior to closing the secsh working group
Thread-Index: Acazb2xlVcODdDMWQl6+PvohomismQBMiSgA
From: "Richard Whalen"
To: "Sam Hartman" ,
Cc:
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
> -----Original Message-----
> From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On
> Behalf Of Sam Hartman
> Sent: Saturday, July 29, 2006 7:15 PM
> To: ietf-ssh@netbsd.org
> Cc: housley@vigilsec.com
> Subject: Formal consultation prior to closing the secsh working group
>=20
: =20
>=20
> I'm very concerned about the filexfer draft. It is well on the way to
> becoming a filesystem, not just an ftp-like protocol. I am concerned
> that we don't have enough reviewers to manage the complexity of the
> draft and to force us to make hard decisions about what features we
> really need. Instead, we're close to including everything. I have
> received several private comments to this effect. I am not sure that
> we have the skill set necessary to design and review a filesystem
> document and I think that is what filexfer is becoming.
The Filexfer draft was never a ftp-like protocol. It was originally a
file access protocol that was missing a text access method. After the
text access method got added it has moved towards becoming a file system
protocol.
I feel that the filexfer draft has grown so much that many don't have
the resources to implement the current drafts, hence many =
implementations
are still a few versions back.
I feel that there is a significant need for the technology though and
would like to see a protocol for the transfer of file data over SSH
standardized. Secsh may not be the right place for this. SSH may be
well enough established that people can think of it as a transport and
that the proper protocol can be developed in the applications area.
I would also like to see the Publickey Subsystem standardized, because
I believe that there is a need for it, though fewer people realize it
because the process of setting up authorization keys is done =
infrequently.
Perhaps its need will become more evident when the security experts
start enforcing the idea that such keys should have expiration dates.
----------------
Richard Whalen
Process Software
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jul 31 09:28:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G7XpG-0006u5-Kx
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 09:28:54 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G7XpF-0001Cb-CY
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 09:28:54 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 4C72A63B1C0; Mon, 31 Jul 2006 13:28:51 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178])
by mail.netbsd.org (Postfix) with ESMTP id 6E99563B172
for ; Mon, 31 Jul 2006 13:28:50 +0000 (UTC)
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
id 96F6FE00C1; Mon, 31 Jul 2006 09:29:24 -0400 (EDT)
From: Sam Hartman
To: Jon Bright
Cc: ietf-ssh@netbsd.org, housley@vigilsec.com
Subject: Re: Formal consultation prior to closing the secsh working group
References: <44CDB12F.30106@siliconcircus.com>
Date: Mon, 31 Jul 2006 09:29:24 -0400
In-Reply-To: <44CDB12F.30106@siliconcircus.com> (Jon Bright's message of "Mon,
31 Jul 2006 09:28:47 +0200")
Message-ID:
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
>>>>> "Jon" == Jon Bright writes:
Jon> Whilst I'm in agreement with regard to your mail, I would
Jon> like to get my shepherding of the Publickey Subsystem
Jon> finished before the WG goes away. It's been through last call
Jon> here, it's been to the RFC editor, it just hasn't been
Jon> published. I've attached my message from 15th July. Perhaps
Jon> you can give me a pointer about what I need to do to get it
Jon> published?
This draft was never submitted to the IESG for publication. The first
step is to submit a new version so it is no longer expired.
The next step is to work out with Bill what he thinks the status is.
If the WG closes and you do not reach agreement with Bill on how to
handle things before then, you can submit for publication as an
individual submission.
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jul 31 11:00:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G7ZFq-00071i-0z
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 11:00:26 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G7ZFo-0002oJ-Hz
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 11:00:26 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id A271663B401; Mon, 31 Jul 2006 15:00:17 +0000 (UTC)
X-Original-To: ietf-ssh@NetBSD.org
Delivered-To: ietf-ssh@NetBSD.org
Received: from mail.siliconcircus.com (mail.siliconcircus.com [62.141.33.102])
by mail.netbsd.org (Postfix) with ESMTP id E2D3C63B260
for ; Mon, 31 Jul 2006 15:00:12 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by mail.siliconcircus.com (Postfix) with ESMTP id 5FBDF10372B;
Mon, 31 Jul 2006 17:00:10 +0200 (CEST)
Message-ID: <44CE1BBE.5010801@siliconcircus.com>
Date: Mon, 31 Jul 2006 17:03:26 +0200
From: Jon Bright
Organization: Silicon Circus Ltd.
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: internet-drafts@ietf.org, ietf-ssh@NetBSD.org
Subject: Submission: draft-ietf-secsh-publickey-subsystem-06.txt
Content-Type: multipart/mixed;
boundary="------------000502010607030405000304"
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22ee92479d98f6ee260f4d663978f084
This is a multi-part message in MIME format.
--------------000502010607030405000304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
Please publish the attached draft-ietf-secsh-publickey-subsystem-06.txt
Thanks,
--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com
--------------000502010607030405000304
Content-Type: text/plain;
name="draft-ietf-secsh-publickey-subsystem-06.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="draft-ietf-secsh-publickey-subsystem-06.txt"
Secure Shell Working Group J. Galbraith
Internet-Draft J. Van Dyke
Intended status: Informational B. McClure
Expires: February 1, 2007 VanDyke Software
J. Bright
Silicon Circus
July 31, 2006
Secure Shell Public-Key Subsystem
draft-ietf-secsh-publickey-subsystem-06.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Draft will expire on February 1, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Galbraith, et al. Expires February 1, 2007 [Page 1]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
Abstract
Secure Shell defines an authentication mechanism that is based on
public keys, but does not define any mechanism for key distribution.
No common key management solution exists in current implementations.
This document describes a protocol that can be used to configure
public keys in an implementation-independent fashion, allowing client
software to take on the burden of this configuration.
This protocol is intended to be used from the Secure Shell Connection
Protocol [4] as a subsystem, as described in the section "Starting a
Shell or a Command". The subsystem name used with this protocol is
"publickey".
The public-key subsystem provides a server-independent mechanism for
clients to add public keys, remove public keys, and list the current
public keys known by the server. Rights to manage public keys are
specific and limited to the authenticated user.
A public key may also be associated with various restrictions,
including a mandatory command or subsystem.
Galbraith, et al. Expires February 1, 2007 [Page 2]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 5
2.1. Opening the Public-Key Subsystem . . . . . . . . . . . . . 5
2.2. Requests and Responses . . . . . . . . . . . . . . . . . . 6
2.3. The Status Message . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 6
2.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 7
3. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 8
3.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 8
3.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 11
3.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 11
3.4. Listing Server Capabilities . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Conventions for Names . . . . . . . . . . . . . . . . 14
5.2.2. Future Assignments of Names . . . . . . . . . . . . . 15
5.3. Request Names . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Response Names . . . . . . . . . . . . . . . . . . . . . . 15
5.5. Attribute Names . . . . . . . . . . . . . . . . . . . . . 15
5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 16
5.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 16
5.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 16
5.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Galbraith, et al. Expires February 1, 2007 [Page 3]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
1. Introduction
Secure Shell is a protocol for secure remote login and other secure
network services over an insecure network. Secure Shell defines an
authentication mechanism that is based on public keys, but does not
define any mechanism for key distribution. Common practice is to
authenticate once with password authentication and transfer the
public key to the server. However, to date no two implementations
use the same mechanism to configure a public key for use.
This document describes a subsystem that can be used to configure
public keys in an implementation-independent fashion. This approach
allows client software to take on the burden of this configuration.
The public-key subsystem protocol is designed for extreme simplicity
in implementation. It is not intended as a PKIX replacement.
The Secure Shell Public-Key subsystem has been designed to run on top
of the Secure Shell transport layer [2] and user authentication
protocols [3]. It provides a simple mechanism for the client to
manage public keys on the server.
This document should be read only after reading the Secure Shell
architecture [1] and Secure Shell connection [4] documents.
This protocol requires that the user be able to authenticate in some
fashion before it can be used. If password authentication is used,
servers SHOULD provide a configuration option to disable the use of
password authentication after the first public key is added.
Galbraith, et al. Expires February 1, 2007 [Page 4]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
2. Public-Key Subsystem Overview
The public-key subsystem provides a server-independent mechanism for
clients to add public keys, remove public keys, and list the current
public keys known by the server. The subsystem name is "publickey".
The public keys added, removed, and listed using this protocol are
specific and limited to those of the authenticated user.
The operations to add, remove, and list the authenticated user's
public keys are performed as request packets sent to the server. The
server sends response packets that indicate success or failure as
well as provide specific response data.
The format of public-key blobs are detailed in the SSH Transport
Protocol document [2].
2.1. Opening the Public-Key Subsystem
The public-key subsystem is started by a client sending an
SSH_MSG_CHANNEL_REQUEST over an existing session's channel.
The details of how a session is opened are described in the SSH
Connection Protocol document [4] in the section "Opening a Session".
To open the public-key subsystem, the client sends:
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "subsystem"
boolean want reply
string "publickey"
Client implementations SHOULD reject this request; it is normally
sent only by the client.
If want reply is TRUE, the server MUST respond with
SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully
started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or
does not support the public-key subsystem.
The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is
not allowed access to the public-key subsystem (for example, because
the user authenticated with a restricted public key).
It is RECOMMENDED that clients request and check the reply for this
request.
Galbraith, et al. Expires February 1, 2007 [Page 5]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
2.2. Requests and Responses
All public-key subsystem requests and responses are sent in the
following form:
uint32 length
string name
... request/response specific data follows
The length field describes the length of the name field and of the
request/response-specific data, but does not include the length of
the length field itself. The client MUST receive acknowledgement of
each request prior to sending a new request.
The version packet, as well as all requests and responses described
in Section 3, are a description of the 'name' field and the data part
of the packet.
2.3. The Status Message
A request is acknowledged by sending a status packet. If there is
data in response to the request, the status packet is sent after all
data has been sent.
string "status"
uint32 status code
string description [RFC-2279]
string language tag [RFC-1766]
A status message MUST be sent for any unrecognized packets, and the
request SHOULD NOT close the subsystem.
2.3.1. Status Codes
The status code gives the status in a more machine-readable format
(suitable for localization), and can have the following values:
SSH_PUBLICKEY_SUCCESS 0
SSH_PUBLICKEY_ACCESS_DENIED 1
SSH_PUBLICKEY_STORAGE_EXCEEDED 2
SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3
SSH_PUBLICKEY_KEY_NOT_FOUND 4
SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5
SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6
SSH_PUBLICKEY_GENERAL_FAILURE 7
SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8
SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9
Galbraith, et al. Expires February 1, 2007 [Page 6]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
If a request completed successfully, the server MUST send the status
code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as
implied by their names.
2.4. The Version Packet
Both sides MUST start by sending a version packet that indicates the
version of the protocol they are using.
string "version"
uint32 protocol-version-number
This document describes version 2 of the protocol.
Both sides send the highest version that they implement. The lower
of the version numbers is the version of the protocol to use. If
either side can't support the lower version, it should close the
subsystem and notify the other side by sending an
SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a
status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED
SHOULD be sent. Note that, normally, status messages are only sent
by the server (in response to requests from the client). This is the
only occasion on which the client sends a status message.
Both sides MUST wait to receive this version before continuing. The
"version" packet MUST NOT be sent again after this initial exchange.
The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent
in response to any other request.
Galbraith, et al. Expires February 1, 2007 [Page 7]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
3. Public-Key Subsystem Operations
The public-key subsystem currently defines four operations: add,
remove, list, and listattributes.
3.1. Adding a Public Key
If the client wishes to add a public key, the client sends:
string "add"
string public-key algorithm name
string public-key blob
boolean overwrite
uint32 attribute-count
string attrib-name
string attrib-value
bool mandatory
repeated attribute-count times
The server MUST attempt to store the public key for the user in the
appropriate location so the public key can be used for subsequent
public-key authentications. If the overwrite field is false and the
specified key already exists, the server MUST return
SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the
client SHOULD provide an option to the user to overwrite the key. If
the overwrite field is true and the specified key already exists, but
cannot be overwritten, the server MUST return
SSH_PUBLICKEY_ACCESS_DENIED.
Attribute names are defined following the same scheme laid out for
algorithm names in [1]. If the server does not implement a mandatory
attribute, it MUST fail the add, with the status code
SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a
mandatory attribute, mere storage of the attribute is not sufficient
-- rather, the server must understand and implement the intent of the
attribute.
The following attributes are currently defined:
"comment"
The value of the comment attribute contains user-specified text about
the public key. The server SHOULD make every effort to preserve this
value and return it with the key during any subsequent list
operation. The server MUST NOT attempt to interpret or act upon the
content of the comment field in any way. The comment attribute must
be specified in UTF-8 format [6].
Galbraith, et al. Expires February 1, 2007 [Page 8]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
The comment field is useful so the user can identify the key without
resorting to comparing its fingerprint. This attribute SHOULD NOT be
mandatory.
"comment-language"
If this attribute is specified, it MUST immediately follow a
"comment" attribute and specify the language for that attribute [5].
The client MAY specify more than one comment if it additionally
specifies a different language for each of those comments. The
server SHOULD attempt to store each comment with its language
attribute. This attribute SHOULD NOT be mandatory.
"command-override"
"command-override" specifies a command to be executed when this key
is in use. The command should be executed by the server when it
receives an "exec" or "shell" request from the client, in place of
the command or shell which would otherwise have been executed as a
result of that request. If the command string is empty, both "exec"
and "shell" requests should be denied. If no "command-override"
attribute is specified, all "exec" and "shell" requests should be
permitted (as long as they satisfy other security or authorization
checks the server may perform). This attribute SHOULD be mandatory.
"subsystem"
"subsystem" specifies a comma-separated list of subsystems that may
be started (using a "subsystem" request) when this key is in use.
This attribute SHOULD be mandatory. If the value is empty, no
subsystems may be started. If the "subsystem" attribute is not
specified, no restrictions are placed on which subsystems may be
started when authenticated using this key.
"x11"
"x11" specifies that X11 forwarding may not be performed when this
key is in use. The attribute-value field SHOULD be empty for this
attribute. This attribute SHOULD be mandatory.
"shell"
"shell" specifies that session channel "shell" requests should be
denied when this key is in use. The attribute-value field SHOULD be
empty for this attribute. This attribute SHOULD be mandatory.
"exec"
Galbraith, et al. Expires February 1, 2007 [Page 9]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
"exec" specifies that session channel "exec" requests should be
denied when this key is in use. The attribute-value field SHOULD be
empty for this attribute. This attribute SHOULD be mandatory.
"agent"
"agent" specifies that session channel "auth-agent-req" requests
should be denied when this key is in use. The attribute-value field
SHOULD be empty for this attribute. This attribute SHOULD be
mandatory.
"env"
"env" specifies that session channel "env" requests should be denied
when this key is in use. The attribute-value field SHOULD be empty
for this attribute. This attribute SHOULD be mandatory.
"from"
"from" specifies a comma-separated list of hosts from which the key
may be used. If a host not in this list attempts to use this key for
authorization purposes, the authorization attempt MUST be denied.
The server SHOULD make a log entry regarding this. The server MAY
provide a method for administrators to disallow the appearance of a
host in this list.
"port-forward"
"port-forward" specifies that no "direct-tcpip" requests should be
accepted, except those to hosts specified in the comma-separated list
supplied as a value to this attribute. If the value of this
attribute is empty, all "direct-tcpip" requests should be refused
when using this key. This attribute SHOULD be mandatory.
"reverse-forward"
"reverse-forward" specifies that no "tcpip-forward" requests should
be accepted, except for the port numbers in the comma-separated list
supplied as a value to this attribute. If the value of this
attribute is empty, all "tcpip-forward" requests should be refused
when using this key. This attribute SHOULD be mandatory.
In addition to the attributes specified by the client, the server MAY
provide a method for administrators to enforce certain attributes
compulsorily.
Galbraith, et al. Expires February 1, 2007 [Page 10]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
3.2. Removing a Public Key
If the client wishes to remove a public key, the client sends:
string "remove"
string public-key algorithm name
string public-key blob
The server MUST attempt to remove the public key for the user from
the appropriate location, so that the public key cannot be used for
subsequent authentications.
3.3. Listing Public Keys
If the client wishes to list the known public keys, the client sends:
string "list"
The server will respond with zero or more of the following responses:
string "publickey"
string public-key algorithm name
string public-key blob
uint32 attribute-count
string attrib-name
string attrib-value
repeated attribute-count times
Following the last "publickey" response, a status packet MUST be
sent.
An implementation MAY choose not to support this request.
3.4. Listing Server Capabilities
If the client wishes to know which key attributes the server
supports, it sends:
string "listattributes"
The server will respond with zero or more of the following responses:
string "attribute"
string attribute name
boolean compulsory
The "compulsory" field indicates whether this attribute will be
compulsorily applied to any added keys (irrespective of whether the
Galbraith, et al. Expires February 1, 2007 [Page 11]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
attribute has been specified by the client) due to administrative
settings on the server. If the server does not support
administrative settings of this nature, it MUST return false in the
compulsory field. An example of use of the "compulsory" attribute
would be a server with a configuration file specifying that the user
is not permitted shell access. Given this, the server would return
the "shell" attribute, with "compulsory" marked true. Whatever
attributes the user subsequently asked the server to apply to their
key, the server would also apply the "shell" attribute, rendering it
impossible for the user to use a shell.
Following the last "attribute" response, a status packet MUST be
sent.
An implementation MAY choose not to support this request.
Galbraith, et al. Expires February 1, 2007 [Page 12]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
4. Security Considerations
This protocol assumes that it is run over a secure channel and that
the endpoints of the channel have been authenticated. Thus, this
protocol assumes that it is externally protected from network-level
attacks.
This protocol provides a mechanism that allows client authentication
data to be uploaded and manipulated. It is the responsibility of the
server implementation to enforce any access controls that may be
required to limit the access allowed for any particular user (the
user being authenticated externally to this protocol, typically using
the SSH User Authentication Protocol [3]). In particular, it is
possible for users to overwrite an existing key on the server with
this protocol, whilst at the same time specifying fewer restrictions
for the new key than were previously present. Servers should take
care that when doing this, clients are not able to override presets
from the server's administrator.
This protocol requires the client to assume that the server will
correctly implement and observe attributes applied to keys.
Implementation errors in the server could cause clients to authorize
keys for access they were not intended to have, or to apply fewer
restrictions than were intended.
Galbraith, et al. Expires February 1, 2007 [Page 13]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
5. IANA Considerations
This section contains conventions used in naming the namespaces, the
initial state of the registry, and instructions for future
assignments.
5.1. Registrations
Consistent with Section 7 of [1], this document makes the following
registration:
The subsystem name "publickey".
5.2. Names
In the following sections, the values for the namespaces are textual.
The conventions and instructions to the IANA for future assignments
are given in this section. The initial assignments are given in
their respective sections.
5.2.1. Conventions for Names
All names registered by the IANA in the following sections MUST be
printable US-ASCII strings, and MUST NOT contain the characters at-
sign ("@"), comma (","), or whitespace or control characters (ASCII
codes 32 or less). Names are case-sensitive, and MUST NOT be longer
than 64 characters.
A provision is made here for locally extensible names. The IANA will
not register, and will not control names with the at-sign in them.
Names with the at-sign in them will have the format of
"name@domainname" (without the double quotes) where the part
preceeding the at-sign is the name. The format of the part preceding
the at-sign is not specified, however these names MUST be printable
US-ASCII strings, and MUST NOT contain the comma character (","), or
whitespace, or control characters (ASCII codes 32 or less). The part
following the at-sign MUST be a valid, fully qualified Internet
domain name [8] controlled by the person or organization defining the
name. Names are case-sensitive, and MUST NOT be longer than 64
characters. It is up to each domain how it manages its local
namespace. It has been noted that these names resemble STD 11 [7]
email addresses. This is purely coincidental and actually has
nothing to do with STD 11 [7]. An example of a locally defined name
is "ourcipher-cbc@example.com" (without the double quotes).
Galbraith, et al. Expires February 1, 2007 [Page 14]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
5.2.2. Future Assignments of Names
Requests for assignments of new Names MUST be done through the IETF
Consensus method as described in [9].
5.3. Request Names
The following table lists the initial assignments of Request names.
Request Name
-------------
version
add
remove
list
listattributes
5.4. Response Names
The following table lists the initial assignments of Response names.
Response Name
--------------
version
status
publickey
attribute
5.5. Attribute Names
Attributes are used to define properties or restrictions for public
keys. The following table lists the initial assignments of Attribute
names.
Attribute Name
---------------
comment
comment-language
command-override
subsystem
x11
shell
exec
agent
env
from
port-forward
reverse-forward
Galbraith, et al. Expires February 1, 2007 [Page 15]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
5.6. Status Codes
The status code is a byte value, describing the status of a request.
5.6.1. Conventions
Status responses have status codes in the range 0 to 255. These
numbers are allocated as follows. Of these, the range 192 to 255 is
reserved for use by local, private extensions.
5.6.2. Initial Assignments
The following table identifies the initial assignments of the status
code values.
Status code Value Reference
------------ ----- ---------
SSH_PUBLICKEY_SUCCESS 0
SSH_PUBLICKEY_ACCESS_DENIED 1
SSH_PUBLICKEY_STORAGE_EXCEEDED 2
SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3
SSH_PUBLICKEY_KEY_NOT_FOUND 4
SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5
SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6
SSH_PUBLICKEY_GENERAL_FAILURE 7
SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8
SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9
5.6.3. Future Assignments
Requests for assignments of new message numbers in the range of 0 to
191 MUST be done through the Standards Action method as described in
[9].
The IANA will not control the message numbers range of 192 through
255. This range will be left for private use.
Galbraith, et al. Expires February 1, 2007 [Page 16]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
6. References
6.1. Normative References
[1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol
Architecture", RFC 4251, January 2006.
[2] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport
Layer Protocol", RFC 4253, January 2006.
[3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006.
[4] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection
Protocol", RFC 4254, January 2006.
[5] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
6.2. Informative References
[7] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[8] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Galbraith, et al. Expires February 1, 2007 [Page 17]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
Authors' Addresses
Joseph Galbraith
VanDyke Software
4848 Tramway Ridge Blvd
Suite 101
Albuquerque, NM 87111
US
Phone: +1 505 332 5700
Email: galb-list@vandyke.com
Jeff P. Van Dyke
VanDyke Software
4848 Tramway Ridge Blvd
Suite 101
Albuquerque, NM 87111
US
Phone: +1 505 332 5700
Email: jpv@vandyke.com
Brent McClure
VanDyke Software
4848 Tramway Ridge Blvd
Suite 101
Albuquerque, NM 87111
US
Phone: +1 505 332 5700
Email: bdm@vandyke.com
Jon Bright
Silicon Circus
24 Jubilee Road
Chichester, West Sussex PO19 7XB
UK
Phone: +49 172 524 0521
Email: jon@siliconcircus.com
Galbraith, et al. Expires February 1, 2007 [Page 18]
Internet-Draft Secure Shell Public-Key Subsystem July 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Galbraith, et al. Expires February 1, 2007 [Page 19]
--------------000502010607030405000304--
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jul 31 22:15:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G7jn9-0000tQ-J4
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 22:15:31 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G7jn8-0001LR-4q
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 22:15:31 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 6815463B444; Tue, 1 Aug 2006 02:15:26 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from dfw0.icgmedia.com (dfw0.icgmedia.com [69.93.3.2])
by mail.netbsd.org (Postfix) with ESMTP id 6812163B43D
for ; Tue, 1 Aug 2006 02:15:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by dfw0.icgmedia.com (Postfix) with ESMTP id A6B38173F0;
Mon, 31 Jul 2006 20:12:34 -0500 (CDT)
Received: from dfw0.icgmedia.com ([127.0.0.1])
by localhost (dfw0 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 02367-04; Mon, 31 Jul 2006 20:12:30 -0500 (CDT)
Received: from netserver.braingia.org (24-197-255-185.dhcp.stpt.wi.charter.com [24.197.255.185])
by dfw0.icgmedia.com (Postfix) with ESMTP id 6ED8317104;
Mon, 31 Jul 2006 20:12:30 -0500 (CDT)
Received: from netserver.braingia.org (netserver.braingia.org [192.168.1.10])
by netserver.braingia.org (8.13.4/8.13.4/Debian-3) with ESMTP id k711CQec017526;
Mon, 31 Jul 2006 20:12:26 -0500
Received: (from suehring@localhost)
by netserver.braingia.org (8.13.4/8.13.4/Submit) id k711CM6S017525;
Mon, 31 Jul 2006 20:12:22 -0500
Date: Mon, 31 Jul 2006 20:12:22 -0500
From: Steve Suehring
To: ietf-ssh@netbsd.org
Cc: housley@vigilsec.com
Subject: Re: Formal consultation prior to closing the secsh working group
Message-ID: <20060801011222.GA17390@mail.braingia.org>
Mail-Followup-To: Steve Suehring ,
ietf-ssh@netbsd.org, housley@vigilsec.com
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at icgmedia.com
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
For my part, I'd like to see the URI draft finalized and passed through. From what I recall, there
was some disagreement over some bits of the SCP and SFTP but the SSH portion was largely finalized.
Therefore, I'd like to propose that the SSH portion of the draft be taken individually. We had talked
about this months ago but never followed through.
Therefore, I can resubmit the draft with just the SSH bits so that it can be progressed if that's
still an option for this WG.
Steve
On Sat, Jul 29, 2006 at 07:15:10PM -0400, Sam Hartman wrote:
>
>
> Hi folks.
>
> The ssh working group has accomplished its primary objective and has
> published the core protocol as RFCs. We've also published several
> related extensions.
>
> We have not managed to publish the filexfer, URI or X.509 drafts.
>
> However, I've come to the conclusion that there is insufficient energy
> in this working group to continue reviewing or producing documents.
> All of our milestones are from 2005. There seems to be no significant
> activity on anything other than the filexfer draft.
>
> I'm very concerned about the filexfer draft. It is well on the way to
> becoming a filesystem, not just an ftp-like protocol. I am concerned
> that we don't have enough reviewers to manage the complexity of the
> draft and to force us to make hard decisions about what features we
> really need. Instead, we're close to including everything. I have
> received several private comments to this effect. I am not sure that
> we have the skill set necessary to design and review a filesystem
> document and I think that is what filexfer is becoming.
>
>
> RFC 2418 defines procedures for creating, managing and terminating of
> working groups. That document stresses the importance of an active
> community of reviewers and subject matter experts. IT makes it clear
> that it is the responsibility of the working group to make sure the
> right people are available to do the work of the WG.
>
> I no longer think this working group has sufficient reviewers or
> contributors. So, I propose to close the working group.
>
> RFC 2418 requires a formal consultation prior to closing a working
> group. This message serves as the beginning of such a consultation.
> I'd like to solicit comments on the proposal to close the secsh
> working group by August 14, 2006.
>
>
> Thanks,
>
> Sam Hartman
> Security Area Director
From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Jul 31 23:32:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1G7kzB-0000uR-Io
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 23:32:01 -0400
Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1G7kzA-0003Kp-0e
for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 31 Jul 2006 23:32:01 -0400
Received: by mail.netbsd.org (Postfix, from userid 0)
id 40EEF63B449; Tue, 1 Aug 2006 03:31:57 +0000 (UTC)
X-Original-To: ietf-ssh@netbsd.org
Delivered-To: ietf-ssh@netbsd.org
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86])
by mail.netbsd.org (Postfix) with ESMTP id 1DAA963B44B
for ; Tue, 1 Aug 2006 03:31:56 +0000 (UTC)
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
by sj-iport-4.cisco.com with ESMTP; 31 Jul 2006 20:31:56 -0700
X-IronPort-AV: i="4.07,200,1151910000";
d="scan'208"; a="1843184617:sNHT27944108"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k713Vt7o011137;
Mon, 31 Jul 2006 20:31:55 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63])
by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k713VtmQ014787;
Mon, 31 Jul 2006 20:31:55 -0700 (PDT)
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 31 Jul 2006 20:31:55 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Formal consultation prior to closing the secsh working group
Date: Mon, 31 Jul 2006 20:31:55 -0700
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Formal consultation prior to closing the secsh working group
Thread-Index: Aca1EGJ94ZjoALnUSNuHi/rGcmeOKwACncww
From: "Joseph Salowey \(jsalowey\)"
To: "Steve Suehring" ,
Cc:
X-OriginalArrivalTime: 01 Aug 2006 03:31:55.0155 (UTC) FILETIME=[094EEE30:01C6B51B]
DKIM-Signature: a=rsa-sha1; q=dns; l=3199; t=1154403115; x=1155267115;
c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20
|Subject:RE=3A=20Formal=20consultation=20prior=20to=20closing=20the=20secsh=20wor
king=20group;
X=v=3Dcisco.com=3B=20h=3DtvRQ0rr0ZH2tqHsIdH5ikXMoFu4=3D; b=oN4Glm3CDpYlgWRYAi9vJkrIFVup4jHu6diFKpOtsxtZgXru54caLAvRdHv7KaOWxdwBlyxX
ZKyEvldkyhbWFMLkHqZtryc7+PS6E1WI+bCrxCQXv2g1I46SSr6uRc64;
Authentication-Results: sj-dkim-8.cisco.com; header.From=jsalowey@cisco.com; dkim=pass (
sig from cisco.com verified; );
Sender: ietf-ssh-owner@NetBSD.org
Precedence: list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
I think it would not be too much work to complete the URI draft for SSH
without SFTP and SCP. I would also like to see this go forward.=20
> -----Original Message-----
> From: ietf-ssh-owner@NetBSD.org=20
> [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Steve Suehring
> Sent: Monday, July 31, 2006 6:12 PM
> To: ietf-ssh@NetBSD.org
> Cc: housley@vigilsec.com
> Subject: Re: Formal consultation prior to closing the secsh=20
> working group
>=20
>=20
> For my part, I'd like to see the URI draft finalized and=20
> passed through. From what I recall, there was some=20
> disagreement over some bits of the SCP and SFTP but the SSH=20
> portion was largely finalized. =20
> Therefore, I'd like to propose that the SSH portion of the=20
> draft be taken individually. We had talked about this months=20
> ago but never followed through.
>=20
> Therefore, I can resubmit the draft with just the SSH bits so=20
> that it can be progressed if that's still an option for this WG.
>=20
> Steve
>=20
> On Sat, Jul 29, 2006 at 07:15:10PM -0400, Sam Hartman wrote:
> >=20
> >=20
> > Hi folks.
> >=20
> > The ssh working group has accomplished its primary=20
> objective and has=20
> > published the core protocol as RFCs. We've also published several=20
> > related extensions.
> >=20
> > We have not managed to publish the filexfer, URI or X.509 drafts.
> >=20
> > However, I've come to the conclusion that there is=20
> insufficient energy=20
> > in this working group to continue reviewing or producing documents.
> > All of our milestones are from 2005. There seems to be no=20
> significant=20
> > activity on anything other than the filexfer draft.
> >=20
> > I'm very concerned about the filexfer draft. It is well on=20
> the way to=20
> > becoming a filesystem, not just an ftp-like protocol. I am=20
> concerned=20
> > that we don't have enough reviewers to manage the complexity of the=20
> > draft and to force us to make hard decisions about what features we=20
> > really need. Instead, we're close to including everything. I have=20
> > received several private comments to this effect. I am not=20
> sure that=20
> > we have the skill set necessary to design and review a filesystem=20
> > document and I think that is what filexfer is becoming.
> >=20
> >=20
> > RFC 2418 defines procedures for creating, managing and=20
> terminating of=20
> > working groups. That document stresses the importance of an active=20
> > community of reviewers and subject matter experts. IT=20
> makes it clear=20
> > that it is the responsibility of the working group to make sure the=20
> > right people are available to do the work of the WG.
> >=20
> > I no longer think this working group has sufficient reviewers or=20
> > contributors. So, I propose to close the working group.
> >=20
> > RFC 2418 requires a formal consultation prior to closing a working=20
> > group. This message serves as the beginning of such a consultation.
> > I'd like to solicit comments on the proposal to close the secsh=20
> > working group by August 14, 2006.
> >=20
> >=20
> > Thanks,
> >=20
> > Sam Hartman
> > Security Area Director
>=20