From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri May 05 20:42:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcAs1-0006a1-7Q for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 05 May 2006 20:42:05 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcArz-0001Wb-OS for secsh-tyoxbijeg7-archive@lists.ietf.org; Fri, 05 May 2006 20:42:05 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id D23B563B223; Fri, 5 May 2006 20:41:54 -0400 (EDT) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by mail.netbsd.org (Postfix) with ESMTP id DC4D563B1E6 for ; Fri, 5 May 2006 20:41:53 -0400 (EDT) Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k460fn6k032517; Fri, 5 May 2006 17:41:49 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k460fnc5032516; Fri, 5 May 2006 17:41:49 -0700 Date: Fri, 5 May 2006 17:41:49 -0700 Message-Id: <200605060041.k460fnc5032516@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4462 on Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-ssh@netbsd.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be A new Request for Comments is now available in online RFC libraries. RFC 4462 Title: Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol Author: J. Hutzelman, J. Salowey, J. Galbraith, V. Welch Status: Standards Track Date: May 2006 Mailbox: jhutz+@cmu.edu, jsalowey@cisco.com, galb@vandyke.com, welch@mcs.anl.gov Pages: 29 Characters: 65280 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-gsskeyex-10.txt URL: http://www.rfc-editor.org/rfc/rfc4462.txt The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion. This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange. This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. [STANDARDS TRACK] This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue May 09 16:59:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZIS-0002rr-FS for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 09 May 2006 16:59:08 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZIQ-00067y-0Z for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 09 May 2006 16:59:08 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id C64A663B1BE; Tue, 9 May 2006 16:58:51 -0400 (EDT) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from orville.25thandClement.com (wilbur.25thandclement.com [64.62.167.198]) by mail.netbsd.org (Postfix) with ESMTP id 0FE9963B1AD for ; Tue, 9 May 2006 16:58:51 -0400 (EDT) Received: from orville.25thandClement.com (william@localhost.25thandClement.com [127.0.0.1]) by orville.25thandClement.com (8.13.4/8.13.4) with ESMTP id k49KwoBV024219 for ; Tue, 9 May 2006 13:58:50 -0700 (PDT) Received: (from william@localhost) by orville.25thandClement.com (8.13.4/8.13.4/Submit) id k49Kwo66028852 for ietf-ssh@NetBSD.org; Tue, 9 May 2006 13:58:50 -0700 (PDT) Date: Tue, 9 May 2006 13:58:49 -0700 From: William Ahern To: ietf-ssh@NetBSD.org Subject: Unix Domain Socket Forwarding Message-ID: <20060509205849.GA29941@orville.25thandClement.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 I'd like to solicit opinions on a protocol for Unix domain socket forwarding. As a proof-of-concept I wrote a patch to OpenSSH 4.3p2 and added the following messages: forwarded-streamlocal@openssh.com direct-streamlocal@openssh.com streamlocal-forward@openssh.com cancel-streamlocal-forward@openssh.com I can go into details on the format of those messages if anybody wishes, but to cut to the chase I'm most interested in hearing what people have to say about umask settings, since some SysV platforms obey file permissions on Unix domain sockets. In my implementation I decided to let each end handle the umask autonomously, partly for simplictity's sake, partly so that the remote side is solely responsible for local policy, and lastly with the notion that "streamlocal" might be translatable on Windows (aside from Cygwin's compatbility layer) and that umask in such a case likely could have no useful meaning. Also, for reverse forwarded connections relayed via the "forwarded-streamlocal" message, the format is a string path followed by name=value pairs terminated by an empty string. The idea here being that interesting information could be relayed, possibly allowing something like getpeereid(2) to be emulated on the other side (getpeereid(2) and similar API's allows the effective uid and gid of the connecting peer to be queried), but only on a best-effort type of basis (since trusting the remote end is a dubious proposition at best). For this piece, I'd also like to hear opinions on whether anybody would chuck that bit for simplicity's sake. The existing OpenSSH patch can be found here: http://www.25thandclement.com/~william/projects/streamlocal.html Oh, and another interesting problem is handling unlinking of existing sockets. Since, unfortunately, Unix domain sockets aren't first class objects in the Unix namespace model, handling dangling socket paths poses some headaches. Again, I left this up to each side, independently. - Bill From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue May 09 20:22:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdcSx-0005jU-8q for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 09 May 2006 20:22:11 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdcSv-00062O-M5 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 09 May 2006 20:22:11 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id BFC0863B2E5; Tue, 9 May 2006 20:21:57 -0400 (EDT) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from smtp.xenetic.net (smtp.xenetic.net [217.77.192.129]) by mail.netbsd.org (Postfix) with ESMTP id 396EB63B16C for ; Tue, 9 May 2006 20:21:55 -0400 (EDT) Received: from SSHEXCH1.ad.ssh.com (sshexch1.ad.ssh.com [217.77.200.204] (may be forged)) by smtp.xenetic.net (8.13.3/8.13.3) with ESMTP id k49MlORt033150 for ; Wed, 10 May 2006 01:47:24 +0300 (EEST) (envelope-from Timo.Rinne@ssh.com) Received: from [127.0.0.1] ([10.1.48.33]) by SSHEXCH1.ad.ssh.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 01:47:22 +0300 Message-ID: <44611C09.2010200@ssh.com> Date: Wed, 10 May 2006 01:47:37 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Unix Domain Socket Forwarding References: <20060509205849.GA29941@orville.25thandClement.com> In-Reply-To: <20060509205849.GA29941@orville.25thandClement.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2006 22:47:23.0453 (UTC) FILETIME=[897EAED0:01C673BA] X-Spam-Flag: NO Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab William Ahern wrote: > I'd like to solicit opinions on a protocol for Unix domain socket > forwarding. > > As a proof-of-concept I wrote a patch to OpenSSH 4.3p2 and added > the following messages: > > forwarded-streamlocal@openssh.com > direct-streamlocal@openssh.com > streamlocal-forward@openssh.com > cancel-streamlocal-forward@openssh.com We have also implemented an extension to connect domain local streams for couple of projects. To circumvent (or ignore) the problem arising from umasks and different local stream implementations and access control systems, we only implemented "direct-local@ssh.com" and left remote forwarding of local streams aside. In my opinion remote forwarding is anyways a feature that is not very often needed but is very often considered harmful by corporate security people. However a few points: 1) In my opinion, this mechanism should be independent of server system specific implementation of local streams. 2) Stream identifiers should be opaque strings, which could look like pathnames in unix server but in some other system they could look something else. 3) Point 2 makes remote forwarding actually somewhat tricky, since the client should then know what kind of local stream naming policy the server host has. 4) It is not absolutely necessary to make stream identifiers to be full pathnames of unix system sockets. Instead the server could maybe prefix the path somehow and maybe do some access control along the way. 5) Some systems don't enforce the access bits to local domain sockets but if they otherwise implement unix filesystem security, the access control can be implemented by setting the access bits of the parent directory to reflect the access policy wanted. We basically only defined an extension channel type and only one format: byte SSH_MSG_CHANNEL_OPEN string "direct-local@ssh.com" uint32 sender channel uint32 initial window size uint32 maximum packet size string opaque local stream endpoint specifier The confirmation message does not have any channel type specific data. > I can go into details on the format of those messages if anybody wishes, but > to cut to the chase I'm most interested in hearing what people have to say > about umask settings, since some SysV platforms obey file permissions on > Unix domain sockets. Since they can't be trusted, the only way is to use subdirectories. I still maintain that the client side method should be independent of this. For example in Windows, the logical choice would be to use named pipes for "local streams". Maybe there could be some kind of access control specifier in the remote forward request that at least could specify whether the socket should be connectable by anybody or only by the user itself. I haven't thought this so much, but to me it seems, that most obvious choice there would be using some kind of mapping between the real socket name and the local stream id. For example local stream /tmp/foo/bar could actually be presented in the server system as unix domain socket /tmp/foo/bar/sock and the permissions of the directory /tmp/foo/bar would be set according to the access control parameters in the request and access bits of the actual socket would be 666 to make everything work identically in systems that enforce the socket node permissions and the ones that do not. Of course all this would be annoying if one wants to listen or connect to local domain sockets not using the naming convention above. > In my implementation I decided to let each end handle the umask > autonomously, partly for simplictity's sake, partly so that the remote side > is solely responsible for local policy, and lastly with the notion that > "streamlocal" might be translatable on Windows (aside from Cygwin's > compatbility layer) and that umask in such a case likely could have no > useful meaning. Absolutely. > Oh, and another interesting problem is handling unlinking of existing > sockets. Since, unfortunately, Unix domain sockets aren't first class > objects in the Unix namespace model, handling dangling socket paths poses > some headaches. Very much so. This was also a reason why I decided to forget the remote forwarding for local streams. In our implementations, the local stream identifier (e.g. unix domain socket pathname) is always discovered by the client some other way and then used as a parameter to "direct-local@ssh.com" request. In this way, client doesn't need to know what kind of semantics (if any) the local stream identifier has. Also the "stream listener" removal is something that is never done by the server but some other component. Of course in remote forwards this would not be the case. > Again, I left this up to each side, independently. I can't see any other way. One scenario that I think remote forwarding might be implemented in a local stream abstraction independent and at least somewhat secure way would be as follows: 1) Client requests the forwarding but does not specify the actual listener. Something like: byte SSH_MSG_GLOBAL_REQUEST string "local-forward@whatever.invalid.domain" boolean want reply (always true) int32 access policy specifier (to be defined) 2) The server generates the path for socket according to the policy using access bits of the socket parent directory. Of course it also creates the directory and the actual socket. Then it returns the identifier of the listener (= unix domain socket path) in: byte SSH_MSG_REQUEST_SUCCESS string opaque local stream endpoint specifier 3) Now client could use this local stream id to connect to the listener just created (e.g. "direct-local@ssh.com" above). In practise it would not connect to the listener itself but rather deliver the endpoint identifier to some other component for connecting either through the secsh connection or locally in the server system. In this scenario the dangling dead sockets would not be a problem, since the server can always generate a path that is free. Regards, -- Timo J. Rinne Valimotie 17 +358 20 500 7000 T Chief Technology Officer FIN-00380 Helsinki +358 20 500 7397 F SSH Communications Security Corp. Finland http://www.ssh.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 25 11:39:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHwB-0001sR-Kp for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 25 May 2006 11:39:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGoD-0005RW-NE for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 25 May 2006 10:27:29 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjGee-0000Yc-9U for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 25 May 2006 10:17:40 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 840E863B178; Thu, 25 May 2006 10:17:32 -0400 (EDT) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail1.soundconcept.net (mail1.soundconcept.net [209.46.121.142]) by mail.netbsd.org (Postfix) with SMTP id DF63363B1FB for ; Thu, 25 May 2006 10:17:31 -0400 (EDT) Received: (qmail 97267 invoked by uid 65534); 25 May 2006 14:17:29 -0000 Date: 25 May 2006 14:17:29 -0000 Message-ID: <20060525141729.97266.qmail@mail1.soundconcept.net> From: mailadmin@soundconcept.net To: ietf-ssh@netbsd.org Subject: FROM ADDRESS NOT FOUND Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: -0.4 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 This mailing list does not accept messages from email addresses that are not on the mailing list. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 25 15:02:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjL69-0005EG-6l for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 25 May 2006 15:02:17 -0400 Received: from mail.netbsd.org ([204.152.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjL67-0004fH-TK for secsh-tyoxbijeg7-archive@lists.ietf.org; Thu, 25 May 2006 15:02:17 -0400 Received: by mail.netbsd.org (Postfix, from userid 0) id 20DE863B128; Thu, 25 May 2006 15:02:05 -0400 (EDT) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from black.gradwell.net (black.gradwell.net [216.218.195.242]) by mail.netbsd.org (Postfix) with ESMTP id 8C4DA63B102 for ; Thu, 25 May 2006 15:02:04 -0400 (EDT) Received: by black.gradwell.net with asmtp (Exim 4.20) id 1FjL5v-000LvW-Py for ietf-ssh@netbsd.org; Thu, 25 May 2006 20:02:03 +0100 Received: from quarantine by sov-mail-b0002.gradwell.net with local (Gradwell gwh-smtpd 1.219) id 4475ff26.4971.4 for ietf-ssh@netbsd.org; Thu, 25 May 2006 20:01:58 +0100 (envelope-sender ) From: hci@bcs.org.uk To: ietf-ssh@netbsd.org Subject: Re: test Message-ID: Date: Thu, 25 May 2006 20:01:58 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 2.0 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hello, Your mail to hci@bcs.org.uk was caught by the SpamAssassin filter running on the bcs.org.uk mail system. To confirm that your mail is genuine, please click this link, or paste it into your browser: https://bcsnet.bcs.org.uk/approve.php?c=4405c45665a985775568d7e1 You will not have to do this again for any mail sent to this recipient (hci@bcs.org.uk). Thank you. -- British Computer Society - www.bcs.org.uk Email Services from gradwell dot com - www.gradwell.com