headers
Bill Sommerfeld | 1 Apr 2005 01:42
Picon

Re: draft-ietf-secsh-gss-keyex and null host keys

On Thu, 2005-03-31 at 14:51, Jeffrey Hutzelman wrote:

> I'm adding the following text to the next version of the draft:

>     <t>Therefore, when a new key for an already-known host is received
>     via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue
>     strong warnings or abort the connection, provided the GSSAPI-based
>     key exchange succeeds.</t>

I think we need to provide additional guidance about hostkey update
acceptance..

one extreme:

In general, manually-exchanged-via-trusted-path hostkeys should not be
replaced by GSSAPI-authenticated ones; the former may be considered akin
to trust anchors.

the other: 

if you learned the hostkey via gssapi, you can learn the new one via
gssapi, too..

							- Bill
Permalink | Reply | 2 comments |
headers
Sam Hartman | 1 Apr 2005 05:22
Picon
Favicon

Re: draft-ietf-secsh-gss-keyex and null host keys

>>>>> "Bill" == Bill Sommerfeld <sommerfeld <at> sun.com> writes:

    Bill> one extreme:

    Bill> In general, manually-exchanged-via-trusted-path hostkeys
    Bill> should not be replaced by GSSAPI-authenticated ones; the
    Bill> former may be considered akin to trust anchors.

I'm not actually sure I believe this is true.  In practice the fact
that there is no good rekeying mechanism for manual keys suggests that
you want to be relatively open in accepting mechanisms to rekey.  For
example I'd sort of like to see a dialogue asking if I wanted to
replace a manual key with a gssapi key if there was one.
Permalink | Reply | 0 comments |
headers
Joseph Galbraith | 1 Apr 2005 19:29
Favicon

Re: comments on draft-ietf-secsh-filexfer-07.txt

Richard Whalen wrote:
> 4.1 Is it ok for a client to use 'version-select' after sending '4'
 > as a requested version number?  Should this state a minimum
 > value of '3'?

Yes, it is okay for a client to use 'version-select' as long as the
initially negotiated version has the SSH_FXP_EXTENDED, the client
can use the 'version-select'

I have however, updated the draft to require that the 'version-select'
be the first request.  This avoids questions about what versionin-flight 
data from the server is using.

I also explicitly allowed a version-downgrade; this might be useful,
if, for example, due to bugs, the negotiated version can't be used.

In addition, I added a 'vendor-id' extension that can be used similarly
to the way the ssh-2.0- ident string is used in the main protocol.
Currently, many implemenations are done in seperate processes, which
makes it hard for them to use the ssh ident string when trying to
detect and work around sftp bugs (like the reversed symlink parameters
bug that several vendors, include us here at vandyke, have.)

> 4.5 "seperated" should be "separated" (multiple occurrences).

Thanks.  Done.

 > In the example of a 'comma-seperated-versions' string the
 > terminating quote after "3,6,7 is missing.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacob Nevins | 1 Apr 2005 22:08
Picon

filexfer: short reads

(This issue is present in filexfer-07, but not new in this version.)

Of SSH_FXP_READ, filexfer-07 states (sec 7.2.1):

| For normal disk files, it is normally guaranteed that this will
| read the specified number of bytes, or up to end of file.
| 
| If the server specified 'max-read-size' then failure to return
| 'length' bytes indicates that EOF or an error occured.

The "guarantee" in the first paragraph doesn't seem to be worth
anything, given the "for normal disk files" (undefined) and even more
vague "normally" hedging.

This is an issue particularly when a client attempts to optimise
transfers by having multiple requests "in flight" simultaneously, as
discussed in sec 10. For instance, if a client issues a series of
reads (say) 4k apart, and the server returns short reads (say 512
bytes), the client then has to have a strategy to fill in the resulting
gaps, and probably some heuristic to guess the read size for the rest of
the file (in the absence of 'max-read-size'). If this guarantee were
usable, this fragmentation/reassembly machinery would not be necessary.

(We've had a report of this in practice -- an OpenVMS server returning
short reads for a ZIP file, apparently due to an implementation detail.
My guess would be that there wouldn't be a way for an SFTP client to
tell that this is anything other then a "normal disk file".)

The "guarantee" should either be made useful, or removed. I suspect
that the right answer is to remove it in the absence of 'max-read-size'
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joseph Galbraith | 1 Apr 2005 22:16
Favicon

Re: filexfer: short reads

Jacob Nevins wrote:
> (This issue is present in filexfer-07, but not new in this version.)
> 
> Of SSH_FXP_READ, filexfer-07 states (sec 7.2.1):
> 
> | For normal disk files, it is normally guaranteed that this will
> | read the specified number of bytes, or up to end of file.
> | 
> | If the server specified 'max-read-size' then failure to return
> | 'length' bytes indicates that EOF or an error occured.
> 
> The "guarantee" in the first paragraph doesn't seem to be worth
> anything, given the "for normal disk files" (undefined) and even more
> vague "normally" hedging.

Thanks... I'll remove it.

> This is an issue particularly when a client attempts to optimise
> transfers by having multiple requests "in flight" simultaneously, as
> discussed in sec 10. For instance, if a client issues a series of
> reads (say) 4k apart, and the server returns short reads (say 512
> bytes), the client then has to have a strategy to fill in the resulting
> gaps, and probably some heuristic to guess the read size for the rest of
> the file (in the absence of 'max-read-size'). If this guarantee were
> usable, this fragmentation/reassembly machinery would not be necessary.

This is exactly the reason I added the max-read-size for.

> (We've had a report of this in practice -- an OpenVMS server returning
> short reads for a ZIP file, apparently due to an implementation detail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Hutzelman | 1 Apr 2005 22:30
Picon
Favicon

Re: draft-ietf-secsh-gss-keyex and null host keys


On Thursday, March 31, 2005 06:42:57 PM -0500 Bill Sommerfeld 
<sommerfeld <at> sun.com> wrote:

> On Thu, 2005-03-31 at 14:51, Jeffrey Hutzelman wrote:
>
>> I'm adding the following text to the next version of the draft:
>
>>     <t>Therefore, when a new key for an already-known host is received
>>     via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue
>>     strong warnings or abort the connection, provided the GSSAPI-based
>>     key exchange succeeds.</t>
>
> I think we need to provide additional guidance about hostkey update
> acceptance..

I don't think we do.  I think that section 4.1 of the architecture document 
provides all the guidance we need in this area, which is mostly a matter 
for policy and configuration.  Our existing security considerations 
RECOMMEND that clients issue a warning when the offered host key does not 
match that cached by the client, on the assumption that such a mismatch is 
an indication of a MitM attack.  But that recommendation is based on the 
fact that in the base protocol, the host key offered by a server is 
completely unauthenticated.  The purpose of the new text is to point out 
that host keys offered during GSSAPI-based key exchange are _not_ 
unauthenticated, and a strong warning is not indicated.  It is still up to 
the implementation and local policy to determine the relative reliability 
of different sources of keys.

BTW, it is worth noting that most implementations do not have any mechanism
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Sommerfeld | 1 Apr 2005 22:36
Picon

core drafts approved by IESG!

If you take a look at:

http://tools.ietf.org/wg/secsh/

you'll note that the five core drafts have been marked "approved --
announcement to be sent".  They were approved during yesterday's IESG
meeting.

To the best of my knowledge this is not an april fool's prank :-)

Thanks to all who have helped make this finally happen.

					- Bill
Permalink | Reply | 0 comments |
headers
Joseph Galbraith | 1 Apr 2005 23:59
Favicon

Re: filexfer-07

der Mouse wrote:
> I just looked over draft-ietf-secsh-filexfer-07.txt and have some
> comments.

Thanks, I appreciate the review.

> Section 3, before the beginning of 3.1, says that "Implementations MUST
> ignore excess data after an otherwise valid packet", but it is not
> clear exactly what this means: it could be taken to mean that extra
> data may appear after a valid [length;type;request-id;data] blob, or
> whether it means that extra data may appear after the data within such
> a blob.  Because of the difficulty of packetizing the octet stream in
> the former, I assume it's the latter, but I think the wording could do
> with clarification.

Thanks.  I've changed it to read:

    Implementations MUST ignore excess data at the end of an otherwise
    valid packet.  Implementation MUST respond to unrecognized packet
    types with an SSH_FX_OP_UNSUPPORTED error.  This will allow the
    protocol to be extended in a backwards compatible way as needed.

Is this better?

> In section 3.2, two is hardly "several"; I'd suggest just "This
> document defines these data types in addition...".

Done.

> In section 3.2, in the definition of "extension-pair", should it read
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph Galbraith | 2 Apr 2005 00:23
Favicon

Publishing filexfer again in a couple of hours...

If you've got comments, holler now!

Thanks,

Joseph
Permalink | Reply | 0 comments |
headers
Richard Whalen | 2 Apr 2005 00:24
Favicon

RE: filexfer-07

> -----Original Message-----
> From: ietf-ssh-owner <at> NetBSD.org [mailto:ietf-ssh-owner <at> NetBSD.org]On
> Behalf Of Joseph Galbraith
> Sent: Friday, April 01, 2005 4:59 PM
> To: der Mouse
> Cc: ietf-ssh <at> NetBSD.org
> Subject: Re: filexfer-07
> 
> > 7.1.1.3, describing SSH_FXF_ACCESS_READ_LOCK: s/gaurantee/guarantee/
> > (twice).  Also, it's not clear whether "the exclusive reader" means
> > with respect to other sftp clients or with respect to all other OS
> > activity; and, an exclusive read lock is a very peculiar 
> thing, and not
> > at all what a "read lock" normally does.
> 
> All right; I renamed it to SSH_FXF_ACCESS_EXCLUSIVE_READ,
> and changed it to say:
> 
>    The server MUST guarantee that no other handle has been
>    opened with ACE4_READ_DATA access, and that no other
>    handle will be opened with ACE4_READ_DATA access until
>    the client closes the handle.  (This MUST apply both
>    to other clients and to other processes on the server.)
> 
>    If there is a conflicting lock the server MUST return
>    SSH_FX_LOCK_CONFLICT.  If the server cannot make the locking
>    guarantee, it MUST return SSH_FX_OP_UNSUPPORTED.
> 
>    Other handles MAY be opened for ACE4_WRITE_DATA or any other
>    access, as long as it does not include ACE4_READ_DATA.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane