From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 1 07:19:05 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484B43A69C0 for ; Thu, 1 Apr 2010 07:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlbeNVySvofu for ; Thu, 1 Apr 2010 07:19:02 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 7E79B3A6A35 for ; Thu, 1 Apr 2010 07:18:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 719E363B182; Thu, 1 Apr 2010 14:19:01 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by mail.netbsd.org (Postfix) with ESMTP id BDB2163B143 for ; Thu, 1 Apr 2010 14:18:59 +0000 (UTC) Received: from MSCS-GH1-UEA02.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id o31EJggV014207; Thu, 1 Apr 2010 14:19:43 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 10:18:57 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Still more feedback on draft-igoe-secsh-x509v3-01 Date: Thu, 1 Apr 2010 10:18:56 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A16@MSIS-GH1-UEA06.corp.nsa.gov> In-reply-to: <4BB3EED0.1090206@vandyke.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Still more feedback on draft-igoe-secsh-x509v3-01 Thread-Index: AcrRNe7BamTMv0RoQO+NKFF3BCI35AAagktg From: "Igoe, Kevin M." To: "Joseph Galbraith" , , "Douglas Stebila" X-OriginalArrivalTime: 01 Apr 2010 14:18:57.0430 (UTC) FILETIME=[444F3B60:01CAD1A6] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > o The chain encoded MAY be incomplete; it is usually not > necessary to include the self-signed certificate specifying > the root authority. >=20 > It is NOT REQUIRED to specify any certificates other than > the senders certificate. If the verifier has a trust anchor > that is not the self signed root, these other certificates may > not be needed. However, omitting certificates from the chain > may make it more likely that certificate verification will fail > because the verifier is not able to build a chain to a trusted > anchor. I'd like our X.509v3 draft to be a "gold standard" for authentication and would prefer an unbroken certificate chain leading back to a=20 root authority. The chain of certs moves the risk that the user's=20 public key is bogus down the chain to the risk that the root's=20 public key is bogus. One can then take measures to mitigate the risk=20 that the root public key is bogus, these measures being well outside=20 the scope of this document.=20 P.S. Having the root self-sign their cert isn't very effective,=20 whence it being optional. > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Joseph Galbraith > Sent: Wednesday, March 31, 2010 8:55 PM > To: ietf-ssh@NetBSD.org > Subject: Still more feedback on draft-igoe-secsh-x509v3-01 >=20 > In section 2. X.509 Version 3 Certificates, we have: >=20 > > o The self-signed certificate specifying the root=20 > authority MAY be > > omitted. >=20 > which seems to indicate that all certificates except the=20 > self-signed certificate at the root MUST be included. >=20 > I'm not sure that's what we want (or if that was actually what was > intended.) >=20 > I think it would be better to say: >=20 > o The chain encoded MAY be incomplete; it is usually not > necessary to include the self-signed certificate specifying > the root authority. >=20 > It is NOT REQUIRED to specify any certificates other than > the senders certificate. If the verifier has a trust anchor > that is not the self signed root, these other certificates may > not be needed. However, omitting certificates from the chain > may make it more likely that certificate verification will fail > because the verifier is not able to build a chain to a trusted > anchor. >=20 > I'm worried in particular that there might be cases where the=20 > signer doesn't have all the certificates necessary to chain=20 > to the root easily available. (I'm not sure if this is a=20 > real life use case or not.) >=20 > If we do decide we want to REQUIRE all the certificates, I=20 > think we should change the paragraph referenced to make that clear: >=20 > o The self-signed certificate specifying the root authority MEY be > omitted. All other certificates in the chain up to the root > authority MUST be included. >=20 > Also, is there any correlation between certificates and OSCP=20 > responses? Currently, there is nothing that constrains the=20 > OCSP responses included to have anything to do with the certificate. >=20 > Is there a need for more than one OCSP response per issuer? > Would it make more sense to do: >=20 > uint32 certificate-count > string certificate > string ocsp-response-from-certificate-issuer > [1..certificate-count] >=20 > Use a 0 length string if no OCSP response is available. >=20 > I'm not sure whether this is a good idea or if I'm just=20 > showing my ignorance. >=20 > Thanks, >=20 > Joseph >=20 >=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 3 07:56:13 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E68B3A67DF for ; Sat, 3 Apr 2010 07:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6fkryhMDT2e for ; Sat, 3 Apr 2010 07:56:12 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 17C093A67AD for ; Sat, 3 Apr 2010 07:56:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BC51763B130; Sat, 3 Apr 2010 14:55:59 +0000 (UTC) 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 E1B7563B102 for ; Sat, 3 Apr 2010 14:55:57 +0000 (UTC) Received: from [192.168.1.193] (account galb [192.168.1.193] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 6405015; Sat, 03 Apr 2010 08:55:56 -0600 Message-ID: <4BB75700.1030703@vandyke.com> Date: Sat, 03 Apr 2010 08:56:00 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Igoe, Kevin M." CC: ietf-ssh@NetBSD.org, Douglas Stebila Subject: Re: Still more feedback on draft-igoe-secsh-x509v3-01 References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A16@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A16@MSIS-GH1-UEA06.corp.nsa.gov> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 4/1/2010 08:18, Igoe, Kevin M. wrote: >> o The chain encoded MAY be incomplete; it is usually not >> necessary to include the self-signed certificate specifying >> the root authority. >> >> It is NOT REQUIRED to specify any certificates other than >> the senders certificate. If the verifier has a trust anchor >> that is not the self signed root, these other certificates may >> not be needed. However, omitting certificates from the chain >> may make it more likely that certificate verification will fail >> because the verifier is not able to build a chain to a trusted >> anchor. > > I'd like our X.509v3 draft to be a "gold standard" for authentication > and would prefer an unbroken certificate chain leading back to a > root authority. The chain of certs moves the risk that the user's > public key is bogus down the chain to the risk that the root's > public key is bogus. One can then take measures to mitigate the risk > that the root public key is bogus, these measures being well outside > the scope of this document. > > P.S. Having the root self-sign their cert isn't very effective, > whence it being optional. I know I sometimes mark an intermediate certificate as trusted in testing. Is this something that happens in the real world? Thanks, Joseph >> -----Original Message----- >> From: ietf-ssh-owner@NetBSD.org >> [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Joseph Galbraith >> Sent: Wednesday, March 31, 2010 8:55 PM >> To: ietf-ssh@NetBSD.org >> Subject: Still more feedback on draft-igoe-secsh-x509v3-01 >> >> In section 2. X.509 Version 3 Certificates, we have: >> >>> o The self-signed certificate specifying the root >> authority MAY be >>> omitted. >> >> which seems to indicate that all certificates except the >> self-signed certificate at the root MUST be included. >> >> I'm not sure that's what we want (or if that was actually what was >> intended.) >> >> I think it would be better to say: >> >> o The chain encoded MAY be incomplete; it is usually not >> necessary to include the self-signed certificate specifying >> the root authority. >> >> It is NOT REQUIRED to specify any certificates other than >> the senders certificate. If the verifier has a trust anchor >> that is not the self signed root, these other certificates may >> not be needed. However, omitting certificates from the chain >> may make it more likely that certificate verification will fail >> because the verifier is not able to build a chain to a trusted >> anchor. >> >> I'm worried in particular that there might be cases where the >> signer doesn't have all the certificates necessary to chain >> to the root easily available. (I'm not sure if this is a >> real life use case or not.) >> >> If we do decide we want to REQUIRE all the certificates, I >> think we should change the paragraph referenced to make that clear: >> >> o The self-signed certificate specifying the root authority MEY be >> omitted. All other certificates in the chain up to the root >> authority MUST be included. >> >> Also, is there any correlation between certificates and OSCP >> responses? Currently, there is nothing that constrains the >> OCSP responses included to have anything to do with the certificate. >> >> Is there a need for more than one OCSP response per issuer? >> Would it make more sense to do: >> >> uint32 certificate-count >> string certificate >> string ocsp-response-from-certificate-issuer >> [1..certificate-count] >> >> Use a 0 length string if no OCSP response is available. >> >> I'm not sure whether this is a good idea or if I'm just >> showing my ignorance. >> >> Thanks, >> >> Joseph >> >> From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 4 21:56:15 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1375E3A68BD for ; Sun, 4 Apr 2010 21:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqfOqDwZ+Z2J for ; Sun, 4 Apr 2010 21:56:14 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3D4033A68B8 for ; Sun, 4 Apr 2010 21:56:10 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4AA4663B10C; Mon, 5 Apr 2010 04:56:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mail.netbsd.org (Postfix) with ESMTP id 1EF7063B109 for ; Mon, 5 Apr 2010 04:56:02 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so1236291qwe.13 for ; Sun, 04 Apr 2010 21:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:received:message-id:subject:from:to :content-type; bh=rfKSuRu9JEQNRD5ncxRcBroe8vbDl3AMV+Kbt6xB8s0=; b=GwnzrvvbQCxaCgQhq6zH0i7q1QdHVa8r64xZKMYbThqu0FfWs4uJj3+6lnDJmI6dLT rYjxqiqjiRHfCt0pdZtRU3xcM8TxsBLP31SimZf9o0LXQVYGOQcdx25K6BvzJGrvUIG9 x+Tkuehs30eG6DUQRLaWmpvYqU+fheldaibao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=RPd8sVY4G5JNiBPub8xSP6HVB9DWmR6Y9Hoxg+5QjA8zpq3UhCbuHkjiR+3b47WpzD eokbthHrF65Ijyc3D5MoGaA/EHByJUA7/zuDPeStkB5eESA7N9MPkjVrBpRJ0suCqqGd Iq0tXvtQebQn+nJJndS340izBmZb4YEAksA9Y= MIME-Version: 1.0 Received: by 10.229.21.200 with HTTP; Sun, 4 Apr 2010 21:56:01 -0700 (PDT) Date: Sun, 4 Apr 2010 21:56:01 -0700 X-Google-Sender-Auth: f0da4938f0bbd034 Received: by 10.229.234.68 with SMTP id kb4mr4134952qcb.103.1270443361424; Sun, 04 Apr 2010 21:56:01 -0700 (PDT) Message-ID: Subject: tunneling and exec channel request support for SSH URIs From: Jim Wigginton To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=ISO-8859-1 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I was thinking about SSH URI's some and I think it'd be neat if the draft for SSH URI's supported tunneling and exec style channel requests. eg. ssh://user@host.example.com/exec:ls%20-la ...or... ssh://user@host.example.com/tunnel:www.google.com:80 As is, the only thing that SSH URI's, as defined in the draft (draft-ietf-secsh-scp-sftp-ssh-uri-04), really support, it seems, are retrieving files via SFTP and opening interactive shells. And although that, I suppose, has its uses, I think SSH URI's could be made a lot more versatile by adding support for the above. From sharonj@ssafara.net Sun Apr 4 22:27:44 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52A83A6890 for ; Sun, 4 Apr 2010 22:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.756 X-Spam-Level: X-Spam-Status: No, score=-4.756 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, AWL=1.300, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_SUB_GOOD_DAY=0.679, US_DOLLARS_3=0.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy2CEktb0+IL for ; Sun, 4 Apr 2010 22:27:39 -0700 (PDT) Received: from gb0135mta02.mail.slb.com (gb0135mta02.mail.slb.com [136.250.9.133]) by core3.amsl.com (Postfix) with ESMTP id 73D6D3A6812 for ; Sun, 4 Apr 2010 22:27:31 -0700 (PDT) Received: from gb0135mta02.mail.slb.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BC7509855D for ; Mon, 5 Apr 2010 05:27:27 +0000 (UTC) Received: from sx006.ddc-nl0105.slb.com (ssa.mail.slb.com [199.6.196.60]) by gb0135mta02.mail.slb.com (Postfix) with ESMTP id F3DF798628 for ; Mon, 5 Apr 2010 05:27:26 +0000 (UTC) Received: from pmxchannel-daemon.ssa.mail.slb.com by ssa.mail.slb.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0L0E00J011TPFO00@ssa.mail.slb.com> for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 05 Apr 2010 05:27:26 +0000 (GMT) Received: from eur.slb.com ([127.0.0.1]) by ssa.mail.slb.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0L0E003G11TO5Q30@ssa.mail.slb.com>; Mon, 05 Apr 2010 05:27:24 +0000 (GMT) Received: from [212.116.219.150] by ssa.mail.slb.com (mshttpd); Sun, 04 Apr 2010 22:27:24 -0700 Date: Sun, 04 Apr 2010 22:27:24 -0700 From: Sharon Johnson Subject: Good Day, Reply to: liutai_ling12@yahoo.com.hk Reply-to: onlineverificationclaim_officer@yahoo.com.hk Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-8.04 (built Feb 28 2007) Content-type: multipart/mixed; boundary="Boundary_(ID_tOppABdGT6zihL6IO9ZSMA)" Content-language: en X-Accept-Language: en Priority: normal To: undisclosed-recipients:; This is a multi-part message in MIME format. --Boundary_(ID_tOppABdGT6zihL6IO9ZSMA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Good Day, I have a Business Proposal of $21,300,000.00 for you to handle with me from my bank. I need to know if you will be able to handle this with me, if you agree to work with me please send me the below details via my email address: {liutai_ling12@yahoo.com.hk} 1,Full names, 2,occupation, 3,private phone number, 4,current residential address. Your earliest response to this letter will be appreciated. --Boundary_(ID_tOppABdGT6zihL6IO9ZSMA) Content-type: text/x-vcard; name=sharonj.vcf; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=sharonj.vcf Content-description: Card for Sharon Johnson begin:vcard n:Breton;Agent Arthur fn:Agent Arthur Breton org:Agent Arthur Breton; version:2.1 email;internet:sharonj@ssafara.net title:Agent Arthur Breton end:vcard --Boundary_(ID_tOppABdGT6zihL6IO9ZSMA)-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 5 07:12:13 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B91328C114 for ; Mon, 5 Apr 2010 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh7llwxOIARA for ; Mon, 5 Apr 2010 07:12:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BBA7F28C103 for ; Mon, 5 Apr 2010 07:12:10 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 43C9863B113; Mon, 5 Apr 2010 14:12:00 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by mail.netbsd.org (Postfix) with ESMTP id 33CFA63B111 for ; Mon, 5 Apr 2010 14:11:58 +0000 (UTC) Received: from MSCS-GH1-UEA03.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o35D1x89006708; Mon, 5 Apr 2010 13:01:59 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA03.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 09:02:25 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Still more feedback on draft-igoe-secsh-x509v3-01 Date: Mon, 5 Apr 2010 09:02:25 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A42@MSIS-GH1-UEA06.corp.nsa.gov> In-reply-to: <4BB75700.1030703@vandyke.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Still more feedback on draft-igoe-secsh-x509v3-01 Thread-Index: AcrTPcXqZ89U9BmcQJ6nkQf2CDSClwBgkGwg From: "Igoe, Kevin M." To: "Joseph Galbraith" Cc: , "Douglas Stebila" X-OriginalArrivalTime: 05 Apr 2010 13:02:25.0899 (UTC) FILETIME=[3D3233B0:01CAD4C0] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > I know I sometimes mark an intermediate certificate as=20 > trusted in testing. Is this something that happens in the real world? >=20 I haven't seen this & neither have the folks I've asked about it. > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com]=20 > Sent: Saturday, April 03, 2010 10:56 AM > To: Igoe, Kevin M. > Cc: ietf-ssh@NetBSD.org; Douglas Stebila > Subject: Re: Still more feedback on draft-igoe-secsh-x509v3-01 >=20 > On 4/1/2010 08:18, Igoe, Kevin M. wrote: > >> o The chain encoded MAY be incomplete; it is usually not > >> necessary to include the self-signed certificate specifying > >> the root authority. > >> > >> It is NOT REQUIRED to specify any certificates other than > >> the senders certificate. If the verifier has a trust anchor > >> that is not the self signed root, these other certificates may > >> not be needed. However, omitting certificates from the chain > >> may make it more likely that certificate verification will fail > >> because the verifier is not able to build a chain to a trusted > >> anchor. > >=20 > > I'd like our X.509v3 draft to be a "gold standard" for=20 > authentication=20 > > and would prefer an unbroken certificate chain leading back=20 > to a root=20 > > authority. The chain of certs moves the risk that the user's public=20 > > key is bogus down the chain to the risk that the root's=20 > public key is=20 > > bogus. One can then take measures to mitigate the risk=20 > that the root=20 > > public key is bogus, these measures being well outside the scope of=20 > > this document. > >=20 > > P.S. Having the root self-sign their cert isn't very=20 > effective, whence=20 > > it being optional. >=20 > I know I sometimes mark an intermediate certificate as=20 > trusted in testing. Is this something that happens in the real world? >=20 > Thanks, >=20 > Joseph >=20 > >> -----Original Message----- > >> From: ietf-ssh-owner@NetBSD.org > >> [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Joseph Galbraith > >> Sent: Wednesday, March 31, 2010 8:55 PM > >> To: ietf-ssh@NetBSD.org > >> Subject: Still more feedback on draft-igoe-secsh-x509v3-01 > >> > >> In section 2. X.509 Version 3 Certificates, we have: > >> > >>> o The self-signed certificate specifying the root > >> authority MAY be > >>> omitted. > >> > >> which seems to indicate that all certificates except the=20 > self-signed=20 > >> certificate at the root MUST be included. > >> > >> I'm not sure that's what we want (or if that was actually what was > >> intended.) > >> > >> I think it would be better to say: > >> > >> o The chain encoded MAY be incomplete; it is usually not > >> necessary to include the self-signed certificate specifying > >> the root authority. > >> > >> It is NOT REQUIRED to specify any certificates other than > >> the senders certificate. If the verifier has a trust anchor > >> that is not the self signed root, these other certificates may > >> not be needed. However, omitting certificates from the chain > >> may make it more likely that certificate verification will fail > >> because the verifier is not able to build a chain to a trusted > >> anchor. > >> > >> I'm worried in particular that there might be cases where=20 > the signer=20 > >> doesn't have all the certificates necessary to chain to the root=20 > >> easily available. (I'm not sure if this is a real life=20 > use case or=20 > >> not.) > >> > >> If we do decide we want to REQUIRE all the certificates, I=20 > think we=20 > >> should change the paragraph referenced to make that clear: > >> > >> o The self-signed certificate specifying the root authority MEY be > >> omitted. All other certificates in the chain up to the root > >> authority MUST be included. > >> > >> Also, is there any correlation between certificates and OSCP=20 > >> responses? Currently, there is nothing that constrains the OCSP=20 > >> responses included to have anything to do with the certificate. > >> > >> Is there a need for more than one OCSP response per issuer? > >> Would it make more sense to do: > >> > >> uint32 certificate-count > >> string certificate > >> string ocsp-response-from-certificate-issuer > >> [1..certificate-count] > >> > >> Use a 0 length string if no OCSP response is available. > >> > >> I'm not sure whether this is a good idea or if I'm just showing my=20 > >> ignorance. > >> > >> Thanks, > >> > >> Joseph > >> > >> >=20 >=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 5 08:31:21 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5376028C166 for ; Mon, 5 Apr 2010 08:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAPErZ9QiKIE for ; Mon, 5 Apr 2010 08:31:20 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A542928C165 for ; Mon, 5 Apr 2010 08:31:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9C33A63B114; Mon, 5 Apr 2010 15:31:14 +0000 (UTC) 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 73A8463B10B for ; Mon, 5 Apr 2010 15:31:09 +0000 (UTC) Received: from [192.168.1.193] (account galb [192.168.1.193] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 6406808; Mon, 05 Apr 2010 09:31:06 -0600 Message-ID: <4BBA0240.8010204@vandyke.com> Date: Mon, 05 Apr 2010 09:31:12 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Igoe, Kevin M." CC: ietf-ssh@NetBSD.org, Douglas Stebila Subject: Re: Still more feedback on draft-igoe-secsh-x509v3-01 References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A42@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A42@MSIS-GH1-UEA06.corp.nsa.gov> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list In that case, if no one else objects, lets change the wording to make it clear that the chain MUST be included, and MUST be complete except for the root certificate. Thanks, Joseph On 4/5/2010 07:02, Igoe, Kevin M. wrote: >> I know I sometimes mark an intermediate certificate as >> trusted in testing. Is this something that happens in the real world? >> > > I haven't seen this & neither have the folks I've asked about it. > > >> -----Original Message----- >> From: Joseph Galbraith [mailto:galb-list@vandyke.com] >> Sent: Saturday, April 03, 2010 10:56 AM >> To: Igoe, Kevin M. >> Cc: ietf-ssh@NetBSD.org; Douglas Stebila >> Subject: Re: Still more feedback on draft-igoe-secsh-x509v3-01 >> >> On 4/1/2010 08:18, Igoe, Kevin M. wrote: >>>> o The chain encoded MAY be incomplete; it is usually not >>>> necessary to include the self-signed certificate specifying >>>> the root authority. >>>> >>>> It is NOT REQUIRED to specify any certificates other than >>>> the senders certificate. If the verifier has a trust anchor >>>> that is not the self signed root, these other certificates may >>>> not be needed. However, omitting certificates from the chain >>>> may make it more likely that certificate verification will fail >>>> because the verifier is not able to build a chain to a trusted >>>> anchor. >>> >>> I'd like our X.509v3 draft to be a "gold standard" for >> authentication >>> and would prefer an unbroken certificate chain leading back >> to a root >>> authority. The chain of certs moves the risk that the user's public >>> key is bogus down the chain to the risk that the root's >> public key is >>> bogus. One can then take measures to mitigate the risk >> that the root >>> public key is bogus, these measures being well outside the scope of >>> this document. >>> >>> P.S. Having the root self-sign their cert isn't very >> effective, whence >>> it being optional. >> >> I know I sometimes mark an intermediate certificate as >> trusted in testing. Is this something that happens in the real world? >> >> Thanks, >> >> Joseph >> >>>> -----Original Message----- >>>> From: ietf-ssh-owner@NetBSD.org >>>> [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Joseph Galbraith >>>> Sent: Wednesday, March 31, 2010 8:55 PM >>>> To: ietf-ssh@NetBSD.org >>>> Subject: Still more feedback on draft-igoe-secsh-x509v3-01 >>>> >>>> In section 2. X.509 Version 3 Certificates, we have: >>>> >>>>> o The self-signed certificate specifying the root >>>> authority MAY be >>>>> omitted. >>>> >>>> which seems to indicate that all certificates except the >> self-signed >>>> certificate at the root MUST be included. >>>> >>>> I'm not sure that's what we want (or if that was actually what was >>>> intended.) >>>> >>>> I think it would be better to say: >>>> >>>> o The chain encoded MAY be incomplete; it is usually not >>>> necessary to include the self-signed certificate specifying >>>> the root authority. >>>> >>>> It is NOT REQUIRED to specify any certificates other than >>>> the senders certificate. If the verifier has a trust anchor >>>> that is not the self signed root, these other certificates may >>>> not be needed. However, omitting certificates from the chain >>>> may make it more likely that certificate verification will fail >>>> because the verifier is not able to build a chain to a trusted >>>> anchor. >>>> >>>> I'm worried in particular that there might be cases where >> the signer >>>> doesn't have all the certificates necessary to chain to the root >>>> easily available. (I'm not sure if this is a real life >> use case or >>>> not.) >>>> >>>> If we do decide we want to REQUIRE all the certificates, I >> think we >>>> should change the paragraph referenced to make that clear: >>>> >>>> o The self-signed certificate specifying the root authority MEY be >>>> omitted. All other certificates in the chain up to the root >>>> authority MUST be included. >>>> >>>> Also, is there any correlation between certificates and OSCP >>>> responses? Currently, there is nothing that constrains the OCSP >>>> responses included to have anything to do with the certificate. >>>> >>>> Is there a need for more than one OCSP response per issuer? >>>> Would it make more sense to do: >>>> >>>> uint32 certificate-count >>>> string certificate >>>> string ocsp-response-from-certificate-issuer >>>> [1..certificate-count] >>>> >>>> Use a 0 length string if no OCSP response is available. >>>> >>>> I'm not sure whether this is a good idea or if I'm just showing my >>>> ignorance. >>>> >>>> Thanks, >>>> >>>> Joseph >>>> >>>> >> >> From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 7 17:59:57 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835403A6829 for ; Wed, 7 Apr 2010 17:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=2.216, BAYES_00=-2.599, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItJiZ217EzOX for ; Wed, 7 Apr 2010 17:59:55 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3A4933A659C for ; Wed, 7 Apr 2010 17:59:54 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 95CB663B156; Thu, 8 Apr 2010 00:59:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from host.iariaservices.org (host.iariaservices.org [67.227.188.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id DA73363B126 for ; Thu, 8 Apr 2010 00:59:39 +0000 (UTC) Received: from c-69-141-162-190.hsd1.de.comcast.net ([69.141.162.190]:51798 helo=OWNER-PC) by host.iariaservices.org with esmtpa (Exim 4.69) (envelope-from ) id 1Nzcsb-00047n-C0 for ietf-ssh@netbsd.org; Wed, 07 Apr 2010 17:33:45 -0400 Date: Wed, 7 Apr 2010 17:33:46 -0400 (EDT) From: ICWMC 2010 To: ietf-ssh@netbsd.org Message-ID: <48316.2601.1270676026541.JavaMail.owner@OWNER-PC> Subject: 3rd CfP: ICWMC 2010 || September 20-25, 2010 - Valencia, Spain MIME-Version: 1.0 Content-Type: text/plain; charset=Cp1252 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.iariaservices.org X-AntiAbuse: Original Domain - netbsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - iarianews.org Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list INVITATION: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please consider to contribute to and/or forward to the appropriate groups t= he following opportunity to submit and publish original scientific results. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ICWMC 2010 | Call for Papers =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL FOR PAPERS, TUTORIALS, PANELS ICWMC 2010: The Sixth International Conference on Wireless and Mobile Commu= nications=20 September 20-25, 2010 - Valencia, Spain General page: http://www.iaria.org/conferences2010/ICWMC10.html Call for Papers: http://www.iaria.org/conferences2010/CfPICWMC10.html Submission deadline: April 20, 2010 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: h= ttp://www.iariajournals.org Publisher: CPS ( see: http://www2.computer.org/portal/web/cscps ) Archived: IEEE CSDL (Computer Science Digital Library) and IEEE Xplore Submitted for indexing: Elsevier's EI Compendex Database, EI's Engineering = Information Index Other indexes are being considered: INSPEC, DBLP, Thomson Reuters Conferenc= e Proceedings Citation Index Please note the Poster Forum and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts= , state of the art, research, standards, implementations, running experimen= ts, applications, and industrial case studies. Authors are invited to submi= t complete unpublished papers, which are not under review in any other conf= erence or journal in the following, but not limited to, topic areas.=20 All tracks are open to both research and industry contributions, in terms o= f Regular papers, Posters, Work in progress, Technical/marketing/business p= resentations, Demos, Tutorials, and Panels. Before submission, please check and conform with the Editorial rules: http:= //www.iaria.org/editorialrules.html =20 ICWMC 2010 Tracks (tracks' topics and submission details: see CfP on the si= te) Wireless Communications Basics Coding & modulation & equalization; Channel modeling and characterization; = Equalization/Synchronization; Transform-domain communication; Multiple acce= ss algorithms and schemes; Antenna and RF subsystems; Smart antennas, adapt= ive antennas, MIMO and beam forming; MIMO and OFDM Based PHY Layer technolo= gies; CDMA Systems Radio Interfaces and Systems Radio communications systems; Radio resource management; Radio transmission= technologies; Power and interference control; Interference Cancellation fo= r Wireless Mobile Systems; Power management for small terminals; Energy map= ; Channel Measurement and Characterization Spectrum Allocation and Management Spectrum efficiency analyses; Dynamic spectrum access networks; Spectrum ma= nagement; Interference mitigation and management techniques=20 Circuits for Wireless Communications Wireless ASICs; Wireless technologies; RF Design issues Wireless and Mobility Mobility management; Location-based services and positioning; Micro and mac= ro-mobility; Mobility, location and handoff management; Mobile and wireless= IP; Wireless broadband mobile access; Routing in multihop, ad hoc and sens= or networks; Wireless multicasting; Wireless mesh networks; Topology contro= l in wireless Protocols for wireless and mobility Wireless protocols, architectural and design concepts; Protocols for air in= terfaces and networks; Wireless MAC protocols: Design and analysis; Transpo= rt layer issues in mobile and wireless networks; Middleware for handhelds a= nd mobile services nodes; Proxies and middleware for wireless networks=20 Traffic and congestion control, QoS, Resource Management Traffic Modeling and Analysis; 3G/4G Bandwidth on Demand; QoS and mobility;= End-to-end QoS; QoS profiling and pricing; Traffic Engineering; Congestion= and admission control=20 Wireless and mobile technologies Wireless LANs; Home and Personal Area Networks: Bluetooth, ZigBeee, etc; Wi= reless MANs:802.16, 802.20; Wireless WANs: 2G/3G/4G; Mobile ad hoc networks= and multi-hop wireless; Sensor networks and applications; Ultra-wideband a= nd short-range networks; High altitude platforms and satellites; Emergency = wireless communications; Wireless real-time communications=20 Performance Evaluation, Simulation and Modeling of wireless networks and sy= stems Performance and QoS in wireless networks; Radio channel modeling (wave prop= agation and measurements); Mobile/wireless networks modeling and simulation= ; Performance of end-to-end protocols over wireless networks=20 Management of wireless and mobile networks=20 Mobility and QoS management; Billing technologies and tools; Policy Based M= anagement in wireless LANS and MANs; Wireless and Mobile Network Planning; = Mobile Database Access and Design Security in wireless and mobile environment Security and robustness in wireless networks; Privacy, Authentication Autho= rization and Accounting (AAA); Encryption and Cryptography; Key Management= Protocols; Digital Rights Management and Multimedia Protection Networks convergence and integration 2G/3G/4G integration; Convergence of 3G wireless and Internet cross-layer d= esign in wireless networks; WLAN/3G/4G integration; Wireless-wireline conve= rgence; Heterogeneous Networks (WAN, Wireless MAN, WLAN); IP Multimedia sub= systems (IMS); Next Generation Network Architecture- mobility issues; Coexi= stence of mobile radio networks; End to End QoS in Heterogeneous environmen= t; Signaling for integrated wireline/wireless networks=20 Applications and services based on wireless infrastructures Mobile & Wireless applications & services; Service discovery: protocols and= frameworks; Personalized services and applications; Audio-visual and mobil= e multimedia applications; Media and content distribution over wireless net= works=20 Standardization and regulations Position on standards & fora on wireless and mobile networks; Wireless Netw= orks Standards and Protocols; Communications regulations; 802.11 WLAN Stand= ards; 802.16 WMAN Standards; 3GPP and 3GPP2 standards; HSDPA Technology and= Standards; Next Generation Network standards=20 Design and implementation=20 Emerging wireless technologies; Cross-layer optimizations in wireless netwo= rks; Design and implementation of mobile information systems; Software defi= ned radio and re-configurability; Joint PHY/MAC design=20 Wireless and mobile network deployment Business models on wireless networks; Market trends and regional developmen= ts; M-commerce; Lessons learnt for wireless deployment in schools Lessons l= earnt for wireless deployment in special regions; Specialized wireless netw= orks; Heterogeneous wireless network deployment (e.g., combining 802.11, 80= 2.16 and 3G networks) Cooperative and Cognitive Vehicular Networks Architectures and platforms of cognitive vehicular network; Distributed art= ificial intelligence techniques for cognitive networks; Cognitive vehicular= routing metrics and supporting protocols; Reduced complexity cognitive net= works; Physical and MAC layer issues; Protocols design for cognitive vehicu= lar networks; Cross-layer optimization in cognitive networks; Security issu= es for vehicular and cognitive networks; Testbed experiment, applications a= nd new advances; Cooperative vehicular networks; QoS provisioning in hetero= geneous networks ; Managing vertical handover; Multihoming; IPv6 GeoNetwork= ing; Vehicular network architectures and protocols ; Cross-layer design and= optimization for vehicular networks and cognitive networks; Mobility manag= ement and topology control; Standardization and Development of vehicular ne= tworks Convergence and social mobility Convergence of mobile networks with the Web 2.0; Convergence on architectur= e and services; Open service capabilities; Open exposure of telco capabilit= ies; Open Web APIs, SOA and SDP); Interworking strategies; Mobile terminals= as sources for User-generated content; Architecture and services for user-= generated content; Auto-description and metadata synthesis for telecom-gene= rated for user-generated content; Social mobile networks; User behavior pro= filing; Social connections (social graphs, contacts, etc); Services and arc= hitectures/solutions for social mobile services =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ICWMC GENERAL CHAIR Jaime Lloret Mauri, Polytechnic University of Valencia, Spain=20 ICWMC Advisory Chairs Silviu Ciochina, University ?Politehnica? Bucharest, Romania=20 Petre Dini, Concordia University, Canada / IARIA, USA Jonathan Loo, Brunel University West London, UK Tudor Palade, Technical University of Cluj-Napoca, Romania=20 Francisco Ramos, Polytechnic University of Valencia, Spain Manuel Sierra P=E9rez, Universidad Polit=E9cnica de Madrid, Spain ICWMC 2010 Research Institute Liaison Chairs Nicolae Crisan, Technical University of Cluj-Napoca, Romania=20 Javier Del Ser Lorente, Tecnalia, Spain=20 Adrian Matei, Politehnica University of Bucharest / Orange Romania S.A., Ro= mania=20 Jyrki Penttinen, Nokia Siemens Networks - Madrid, Spain / Helsinki Universi= ty of Technology, Finland=20 Tomi R=E4ty, VTT Technical Research Centre of Finland, Finland=20 ICWMC 2010 Industry/Research Chairs Jos=E9 Garc=EDa, La Maquinista Valenciana, Spain=20 Jingli Li, TopWorx - Emerson, USA=20 Christopher Nguyen, Intel Corp., USA=20 Horia Stefanescu, Orange, Romania =20 Special Area Chairs Cooperative and Cognitive Vehicular Networks Area Chairs: Yacine Khaled, Geenov, France Jong-Hyouk Lee, Sungkyunkwan University, Korea // INRIA, France Committee members: http://www.iaria.org/conferences2010/ComICWMC10.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From bkindle@stanford.edu Thu Apr 8 08:33:06 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65F93A6AA4 for ; Thu, 8 Apr 2010 08:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.279 X-Spam-Level: X-Spam-Status: No, score=-4.279 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, AWL=0.456, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, US_DOLLARS_3=0.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZK0+S7RkJmz for ; Thu, 8 Apr 2010 08:33:06 -0700 (PDT) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by core3.amsl.com (Postfix) with ESMTP id 215983A6A87 for ; Thu, 8 Apr 2010 08:33:06 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7F2871A16B6; Thu, 8 Apr 2010 08:22:40 -0700 (PDT) Received: from zm04.stanford.edu (zm04.Stanford.EDU [171.67.219.154]) by smtp.stanford.edu (Postfix) with ESMTP id 962BB1A16A3; Thu, 8 Apr 2010 08:22:31 -0700 (PDT) Date: Thu, 8 Apr 2010 08:22:31 -0700 (PDT) From: Mike kevin Reply-To: Mike kevin Message-ID: <2133550529.980401270740151560.JavaMail.root@zm04.stanford.edu> Subject: I need your Swiftly reply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [212.116.219.150] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (zclient/5.0.21_GA_3150.RHEL4_64) X-Authenticated-User: bkindle@stanford.edu To: undisclosed-recipients:; Hello, I am Mr. Mike Kevin I have a business proposal of $11,000.000.00 USD, for you to handle with me from my bank. If interested, please send me your full contact details and after that I shall provide you with more details of the business. Please contact me on this email: mikekevin@web2mail.com. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 12 10:24:56 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3098128C16F for ; Mon, 12 Apr 2010 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mV54K+fKhY+n for ; Mon, 12 Apr 2010 10:24:54 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 71FB03A69B6 for ; Mon, 12 Apr 2010 10:22:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DDDA463B132; Mon, 12 Apr 2010 17:22:00 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet12.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 49F3D63B12C for ; Mon, 12 Apr 2010 17:21:59 +0000 (UTC) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3CHLc4J010045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Apr 2010 17:21:40 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3CCbS8d004417; Mon, 12 Apr 2010 17:21:38 GMT Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 167727101271092878; Mon, 12 Apr 2010 10:21:18 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 10:21:17 -0700 Date: Mon, 12 Apr 2010 12:21:13 -0500 From: Nicolas Williams To: Jim Wigginton Cc: ietf-ssh@NetBSD.org Subject: Re: tunneling and exec channel request support for SSH URIs Message-ID: <20100412172112.GM10389@Sun.COM> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BC356A2.015D:SCFMA4539814,ss=1,fgs=0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sun, Apr 04, 2010 at 09:56:01PM -0700, Jim Wigginton wrote: > I was thinking about SSH URI's some and I think it'd be neat if the > draft for SSH URI's supported tunneling and exec style channel > requests. eg. > > ssh://user@host.example.com/exec:ls%20-la > > ...or... > > ssh://user@host.example.com/tunnel:www.google.com:80 > > As is, the only thing that SSH URI's, as defined in the draft > (draft-ietf-secsh-scp-sftp-ssh-uri-04), really support, it seems, are > retrieving files via SFTP and opening interactive shells. And > although that, I suppose, has its uses, I think SSH URI's could be > made a lot more versatile by adding support for the above. Good point. But where should we stop? Does agent forwarding need to be specifiable through the ssh URI scheme? What about GSS-API credential delegation? Will users know to check for this? (no!) How would we protect users from accidentally forwarding agents/credentials to untrusted servers? What about specifying which userauth methods to try? I could go on. Frankly, I'm scared. We could make a great many options available in the ssh URI scheme, of that I'm sure. But which ones should we? My take: - Agent/credential delegation -> must NOT be specifiable through URI, but if we must allow it then we must say that the client UI MUST check with the user at least once (and may cache the server as trusted/not-trusted thereafter). - Userauth method -> it's likely useful to restrict URIs to non- interative userauth (publickey, hostbased, and GSS-API). - Passwords -> danger, Will Robinson; I prefer that passwords not be specifiable in URIs. (Also, passwords won't necessarily play well with keyboard-interactive as the server might be interested in more than just a password.) - Keyex, host auth, cipher, compression algs -> I don't see the need to specify these, and it'd likely be dangerous. However, being able to specify sets of suites by "strength level" using a standard mechanism of some sort (e.g., standard names, such as FIPS-140) would be nice. - Channels... -> if we're going to allow for one channel to be specified, we should allow for multiple channels (so one URI could be used to setup multiple port forwards). - All channels should be confirmed by the UI with the user: - Remote commands could be dangerous to the user; - Port forwardings could be dangerous to the user. - pty? -> pty should NOT be specifiable in the URI scheme because what really matters is whether the client has a [virtual] terminal. However, no-pty might be something we want to specify in a URI. That is, whether a pty is requested should depend on whether the client can handle it, but it should be possible to request that no pty be used. - Port forwarding -> both directions should be allowed to be specified in URIs, both subject to UI confirmation. - 'GatewayPorts'? -> should definitely not be specifiable through URI. - There's surely others I'm not thinking of at the moment. Connect timeouts, keepalives, ... Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 12 12:26:12 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1CE3A6A49 for ; Mon, 12 Apr 2010 12:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQfuvYQFPT2V for ; Mon, 12 Apr 2010 12:26:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 451F93A6898 for ; Mon, 12 Apr 2010 12:26:06 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 579F763B148; Mon, 12 Apr 2010 19:25:50 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from web51405.mail.re2.yahoo.com (web51405.mail.re2.yahoo.com [206.190.38.184]) by mail.netbsd.org (Postfix) with SMTP id 5665563B143 for ; Mon, 12 Apr 2010 19:25:48 +0000 (UTC) Received: (qmail 58847 invoked by uid 60001); 12 Apr 2010 17:39:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271093947; bh=oCW6X/feMprDI5CN7XF864CyRMUrt1tKSC5RXVPkUbo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=r94YR6M7LjRGOBeg5LiokkU8xkwmj0grvHZKghx0Q6oAGyriax/hCMvZxXsUGVX7K/QGIo16owp/OhcBMhRFm/UtwFH+JGT2k+Cdda4b7C9bTB5JvMZ4YNx9fQWEcJH3c5rbFqT2nRhLMzjWcOvPr6/VQ6pZhwAmpT1I7eCCKyQ= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=e39b3nohyTiSJIQq5EPmCsKmFv8DHJmx8z9iaY5YfBXrL5D+xDR5mpnd0afKNvNlnDgH7clArQLjo3RZMrRQKuAJG9WUqiPp4vq9fooC+X7eMWrn4KLgis4zTQ3srqj1YJInzFpx9Js7GJZGUodIGKzjfW3nOiLmHfyTAiIbN7k=; Message-ID: <750210.58797.qm@web51405.mail.re2.yahoo.com> X-YMail-OSG: bSe1LEwVM1ljighdd8Mph9ryBVw4BpK3XBvG.k1Av6dDavw U73UaE9JFke1ZT6QqFAd44OPJLvSU4NiKD9hLrCK0.biznz5M.0czaDEtYcZ rirUb.ni6NYXpY77OiVSuxUqAiRhGJaHgn3W5lQeWoDE1uLEGqt3VjwmR3so Y0CYfV7AlWwIO1AgLWJd2akIdAfnc90BqPw.KNNRLTGvS49Q.boK.SlDVETW aIk9zwmqPwcEjy7evtlLpTFb71FIpoNFj.FUvTLBDHSj9ELYf2CrVSm40._M TDN8eladlr61JusxLG5w25FTLYKj3V.y1nHpUumi3KUYglKlHi0lLDsjrnUB _hnf7CZHPW636ZhSE8BTcezMieZBA Received: from [129.116.66.226] by web51405.mail.re2.yahoo.com via HTTP; Mon, 12 Apr 2010 10:39:07 PDT X-Mailer: YahooMailRC/348.3 YahooMailWebService/0.8.100.260964 Date: Mon, 12 Apr 2010 10:39:07 -0700 (PDT) From: Thomas Anderson Subject: Re: tunneling and exec channel request support for SSH URIs To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 4/12/2010 12:21 PM, Nicolas Williams wrote: > On Sun, Apr 04, 2010 at 09:56:01PM -0700, Jim Wigginton wrote: >> I was thinking about SSH URI's some and I think it'd be neat if the >> draft for SSH URI's supported tunneling and exec style channel >> requests. eg. >> >> ssh://user@host.example.com/exec:ls%20-la >> >> ...or... >> >> ssh://user@host.example.com/tunnel:www.google.com:80 >> >> As is, the only thing that SSH URI's, as defined in the draft >> (draft-ietf-secsh-scp-sftp-ssh-uri-04), really support, it seems, are >> retrieving files via SFTP and opening interactive shells. And >> although that, I suppose, has its uses, I think SSH URI's could be >> made a lot more versatile by adding support for the above. > > Good point. But where should we stop? Does agent forwarding need to be > specifiable through the ssh URI scheme? What about GSS-API credential > delegation? Will users know to check for this? (no!) How would we > protect users from accidentally forwarding agents/credentials to > untrusted servers? What about specifying which userauth methods to try? > > I could go on. Frankly, I'm scared. We could make a great many options > available in the ssh URI scheme, of that I'm sure. But which ones > should we? > > My take: > > - Agent/credential delegation -> must NOT be specifiable through URI, > but if we must allow it then we must say that the client UI MUST > check with the user at least once (and may cache the server as > trusted/not-trusted thereafter). > > - Userauth method -> it's likely useful to restrict URIs to non- > interative userauth (publickey, hostbased, and GSS-API). > > - Passwords -> danger, Will Robinson; I prefer that passwords not be > specifiable in URIs. (Also, passwords won't necessarily play well > with keyboard-interactive as the server might be interested in > more than just a password.) > > - Keyex, host auth, cipher, compression algs -> I don't see the need to > specify these, and it'd likely be dangerous. However, being able to > specify sets of suites by "strength level" using a standard mechanism > of some sort (e.g., standard names, such as FIPS-140) would be nice. > > - Channels... -> if we're going to allow for one channel to be > specified, we should allow for multiple channels (so one URI could be > used to setup multiple port forwards). > > - All channels should be confirmed by the UI with the user: > > - Remote commands could be dangerous to the user; > - Port forwardings could be dangerous to the user. > > - pty? -> pty should NOT be specifiable in the URI scheme because > what really matters is whether the client has a [virtual] > terminal. However, no-pty might be something we want to specify > in a URI. That is, whether a pty is requested should depend on > whether the client can handle it, but it should be possible to > request that no pty be used. > > - Port forwarding -> both directions should be allowed to be > specified in URIs, both subject to UI confirmation. > > - 'GatewayPorts'? -> should definitely not be specifiable through URI. > > - There's surely others I'm not thinking of at the moment. Connect > timeouts, keepalives, ... > > Nico The SSH URI no more has to support every single possible SSH option than the HTTP URI supports every single HTTP option. There's no HTTP URI setting to use compression, keepalive's, to set cookies, etc, so why would you expect them in the SSH URI? And similarly, there's no key exchange algorithm, encryption algorithm, compression algorithm, etc parameters for the HTTPS URI. I also don't see the danger, at all, in port forwarding. Instead of connecting to http://www.google.com you connect to ssh://domain.tld/http://google.com or whatever. Could domain.tld be an "evil" SSH server? Sure, but then, google.com could be subjected to MITM or users could, through social engineering, be tricked into clicking on googlephishingscam.com. Besides, presumably users would realize that they're connecting to a new SSH server when they're asked if they want to save the server signature. Honestly, right now, I think PHP's SSH URI format is better than the one proposed in the current draft: http://www.php.net/manual/en/wrappers.ssh2.php From webupdate_team@mail2webmaster.com Mon Apr 12 23:25:28 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9048B3A6853 for ; Mon, 12 Apr 2010 23:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.106 X-Spam-Level: **** X-Spam-Status: No, score=4.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_SOMETHING=1.605, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EniFclVlJV1Q for ; Mon, 12 Apr 2010 23:25:25 -0700 (PDT) Received: from relay.imagine.ie (dns2.dns.imagine.ie [87.232.1.41]) by core3.amsl.com (Postfix) with ESMTP id 943F73A6774 for ; Mon, 12 Apr 2010 23:25:25 -0700 (PDT) Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 4C532237B47; Tue, 13 Apr 2010 07:25:18 +0100 (IST) Received: from gaelic.ie (www1.int.imagine.ie [87.232.1.156]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id o3D6OuBK017832; Tue, 13 Apr 2010 07:24:57 +0100 Received: from 212.116.219.150 ([212.116.219.150]) by webmail.gaelic.ie (Horde MIME library) with HTTP; Tue, 13 Apr 2010 07:24:55 +0100 Message-ID: <20100413072455.jx84cse4mio00w8g@webmail.gaelic.ie> X-IMAP-User: danield@gaelic.ie Date: Tue, 13 Apr 2010 07:24:55 +0100 From: Web-Mail Admin To: undisclosed-recipients:; Subject: Dear Web-Mail Account Owner MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4-cvs) X-Bayes-Prob: 0.0001 (Score 0) X-Canit-Stats-ID: 69093924 - 153d9b2dcf4c X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.152 Dear Account Owner: It has come to our notice that your email has not passed the verification/Update process that we are presently working on. We are currently upgrading our data base and e-mail account center .We are deleting all Old Web mail email account to create more space for new accounts. To prevent your account from closing you will have to update it so that we will know that it's a present used account. To complete your account re-confirmation, you must reply to this email immediately and enter your account details as requested below. *********************************************** Email User-name :........ ..... EMAIL Password :............... Date of Birth :............... Country or Territory :........ ************************************************ ****IMPORTANT : This updating is compulsory as a result of our recent server changes. If you fail to update your email address you will soon be unable to receive/send mails.Also your email will not be equipped with the latest anti-virus system in our new servers. This will make your email and PC vulnerable to virus attacks from the internet. **** HOW TO UPDATE: To update simply reply the above to upgrading admin as appropriate.Failure to do so immediately will lead to SUSPENSION OF YOUR ACCOUNT. Thanks for your co-operation, Web-mail Administrator WEB MAIL BETA ---------------------------------------------------------------- Free broadband from Gaelic Telecom! http://www.gaelictelecom.ie/ From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 13 12:22:53 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF9828C10C for ; Tue, 13 Apr 2010 12:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhXRnurCOWll for ; Tue, 13 Apr 2010 12:22:48 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 5F1263A67D2 for ; Tue, 13 Apr 2010 12:22:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B0C5063B146; Tue, 13 Apr 2010 19:22:31 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id BF3A363B125 for ; Tue, 13 Apr 2010 19:22:29 +0000 (UTC) Received: from [192.168.0.104] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o3DIFjVg014958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 14:15:47 -0400 (EDT) Date: Tue, 13 Apr 2010 14:15:44 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Jim Wigginton cc: ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: tunneling and exec channel request support for SSH URIs Message-ID: <699E2DFCB2765DC2E00628CF@atlantis.pc.cs.cmu.edu> In-Reply-To: <20100412172112.GM10389@Sun.COM> References: <20100412172112.GM10389@Sun.COM> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Monday, April 12, 2010 12:21:13 PM -0500 Nicolas Williams wrote: > On Sun, Apr 04, 2010 at 09:56:01PM -0700, Jim Wigginton wrote: >> I was thinking about SSH URI's some and I think it'd be neat if the >> draft for SSH URI's supported tunneling and exec style channel >> requests. eg. >> >> ssh://user@host.example.com/exec:ls%20-la >> >> ...or... >> >> ssh://user@host.example.com/tunnel:www.google.com:80 >> >> As is, the only thing that SSH URI's, as defined in the draft >> (draft-ietf-secsh-scp-sftp-ssh-uri-04), really support, it seems, are >> retrieving files via SFTP and opening interactive shells. And >> although that, I suppose, has its uses, I think SSH URI's could be >> made a lot more versatile by adding support for the above. > > Good point. But where should we stop? A URI should identify a resource. That is, it should identify some particular object or service, such as an interactive shell, a file in SFTP (arguably this should be a distinct URI scheme), or some other subsystem. It does not need to and probably should not be capable of expressing configuration of parameters that control how we talk to the ssh server, such as algorithm selection. IMHO... - We _do_ want to be able to specify a username, and yes, even a password. Remember, you're not expressing the password of the user following the URI; you're expressing the password needed to access the resource. It is common to set up a resource which requires a username and password, and then advertise the username and password to a limited audience. - We _do_ want to be able to have URI's that refer to interactive shells, if only because this is the "main" service SSH provides. - We _do_ want to be able to have URI's that refer to connections to arbitrary subsystems. Some subsystems may be more useful to access in this way than others. - We _do_ want to be able to have URI's that refer to specific files accessed via SFTP. However, this probably wants to be a separate URI scheme. - We _do_ want to be able to have URI's that establish tunnels which allow the SSH client to connect to services on the SSH server's network. This type of tunnel is a common use of SSH, and makes sense both as a service and as a URI resource. It poses no threat to the user of such a URI, provided the selection of a port on the client end is up to the SSH client and _not_ contained in the URI, and that the SSH client takes the usual precautions for such tunnels. - We do _not_ want to be able to have URI's that establish tunnels which allow the SSH server to connect to services on the SSH client's network. - We do _not_ want URI's to be able to express preferences for algorithm selection in any form. This would amount to allowing the provider of a URI to override the client's security policy, which is a bad idea. - A user agent may wish to restrict what userauth methods can be used, based on its ability to handle user interaction or on local security policy. In fact, we probably should offer advice about taking care with the use of non-interactive authentication methods, lest an attacker trick a user into issuing a command to some service. - In a similar vein, probably we should not allow SSH URI's that direct the user to execute a particular command on a remote SSH server. That sounds exceedingly dangerous. - And, an SSH URI should not be able to control behaviors like agent forwarding, which again are a matter of client security policy and should not be subject to override. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 14 01:49:29 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347113A69C0 for ; Wed, 14 Apr 2010 01:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0c5Zn9LmH+Q for ; Wed, 14 Apr 2010 01:49:28 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 604233A684B for ; Wed, 14 Apr 2010 01:49:27 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D812463B14B; Wed, 14 Apr 2010 08:49:16 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id E844863B14C for ; Wed, 14 Apr 2010 08:49:13 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F394040014; Wed, 14 Apr 2010 10:49:10 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id E65054000F; Wed, 14 Apr 2010 10:49:10 +0200 (CEST) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id B9FDC4000F; Wed, 14 Apr 2010 10:49:10 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id o3E8nAfM022831; Wed, 14 Apr 2010 10:49:10 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id o3E8n8NC022830; Wed, 14 Apr 2010 10:49:08 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Jeffrey Hutzelman Cc: Nicolas Williams , Jim Wigginton , ietf-ssh@NetBSD.org Subject: Re: tunneling and exec channel request support for SSH URIs References: <20100412172112.GM10389@Sun.COM> <699E2DFCB2765DC2E00628CF@atlantis.pc.cs.cmu.edu> Date: Wed, 14 Apr 2010 10:49:08 +0200 In-Reply-To: <699E2DFCB2765DC2E00628CF@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 13 Apr 2010 14:15:44 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman writes: > IMHO... > > - We _do_ want to be able to specify a username, and yes, even a password. > Remember, you're not expressing the password of the user following the > URI; you're expressing the password needed to access the resource. It > is common to set up a resource which requires a username and password, > and then advertise the username and password to a limited audience. > > - We _do_ want to be able to have URI's that refer to interactive > shells, if only because this is the "main" service SSH provides. > > - We _do_ want to be able to have URI's that refer to connections > to arbitrary subsystems. Some subsystems may be more useful to access > in this way than others. > > - We _do_ want to be able to have URI's that refer to specific files > accessed via SFTP. However, this probably wants to be a separate > URI scheme. > > - We _do_ want to be able to have URI's that establish tunnels which > allow the SSH client to connect to services on the SSH server's network. > This type of tunnel is a common use of SSH, and makes sense both as a > service and as a URI resource. It poses no threat to the user of such > a URI, provided the selection of a port on the client end is up to the > SSH client and _not_ contained in the URI, and that the SSH client takes > the usual precautions for such tunnels. > > - We do _not_ want to be able to have URI's that establish tunnels which > allow the SSH server to connect to services on the SSH client's network. > > - We do _not_ want URI's to be able to express preferences for algorithm > selection in any form. This would amount to allowing the provider of a > URI to override the client's security policy, which is a bad idea. > > - A user agent may wish to restrict what userauth methods can be used, > based on its ability to handle user interaction or on local security > policy. In fact, we probably should offer advice about taking care > with the use of non-interactive authentication methods, lest an attacker > trick a user into issuing a command to some service. > > - In a similar vein, probably we should not allow SSH URI's that direct > the user to execute a particular command on a remote SSH server. That > sounds exceedingly dangerous. > > - And, an SSH URI should not be able to control behaviors like agent > forwarding, which again are a matter of client security policy and > should not be subject to override. All of this makes sense to me. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 14 04:15:44 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC8228C1C4 for ; Wed, 14 Apr 2010 04:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ndpyPaqPyEO for ; Wed, 14 Apr 2010 04:15:43 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4175C28C1C2 for ; Wed, 14 Apr 2010 04:11:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CE1DE63B163; Wed, 14 Apr 2010 11:11:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id D632B63B15A for ; Wed, 14 Apr 2010 11:11:43 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1O1zSM-0002kB-06; Wed, 14 Apr 2010 11:04:26 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <699E2DFCB2765DC2E00628CF@atlantis.pc.cs.cmu.edu> Subject: Re: tunneling and exec channel request support for SSH URIs MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 14 Apr 2010 11:04:26 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman wrote: > - We _do_ want to be able to have URI's that refer to connections > to arbitrary subsystems. Some subsystems may be more useful to access > in this way than others. [...] > - [...] probably we should not allow SSH URI's that direct > the user to execute a particular command on a remote SSH server. That > sounds exceedingly dangerous. I'm unconvinced that these two points are really consistent with each other. If I want to set up a custom service on a given SSH server, I might find it inconvenient to invent a new subsystem name, or to set up a special account whose shell is the service program, so I might prefer to provide service users with a command to run. Drawing a hard dividing line between "subsystem" and "exec" seems like the wrong answer to me. The real danger is URIs which combine a specific command with the user's _personal_ credentials. There's no danger in 'ssh to this specialist service machine, log in as specialist-service, and run specialist-service-command', but there is danger in 'ssh to this server you had an account on anyway, implicitly log in as yourself due to already having an SSH agent active and the URI not specifying a username to override your own, and run "rm -rf *"'. So perhaps the right answer is to constrain both command and general-subsystem specifications to the case in which full authentication credentials (e.g. username _and_ password) are also provided in the URI _and authentication with those credentials succeeds_? -- Simon Tatham "infinite loop _see_ loop, infinite" - Index, Borland Pascal Language Guide From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 14 08:35:23 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9533A68B9 for ; Wed, 14 Apr 2010 08:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.553 X-Spam-Level: X-Spam-Status: No, score=-4.553 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuxZt9BbkO9C for ; Wed, 14 Apr 2010 08:35:23 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 6217B3A67EC for ; Wed, 14 Apr 2010 08:35:22 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B7F5963B152; Wed, 14 Apr 2010 15:35:11 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet14.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 5842C63B160 for ; Wed, 14 Apr 2010 15:35:09 +0000 (UTC) Received: from rcsinet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rcsinet14.oracle.com (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id o3EFZ8dT026994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Apr 2010 15:35:08 GMT Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3EFYk9O004199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Apr 2010 15:34:47 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3EFYg0b029340; Wed, 14 Apr 2010 15:34:42 GMT Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 160309871271259238; Wed, 14 Apr 2010 08:33:58 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Apr 2010 08:33:55 -0700 Date: Wed, 14 Apr 2010 10:33:50 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Jim Wigginton , ietf-ssh@NetBSD.org Subject: Re: tunneling and exec channel request support for SSH URIs Message-ID: <20100414153350.GD10389@Sun.COM> References: <20100412172112.GM10389@Sun.COM> <699E2DFCB2765DC2E00628CF@atlantis.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <699E2DFCB2765DC2E00628CF@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BC5E095.018D:SCFMA4539814,ss=1,fgs=0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, Apr 13, 2010 at 02:15:44PM -0400, Jeffrey Hutzelman wrote: > --On Monday, April 12, 2010 12:21:13 PM -0500 Nicolas Williams > wrote: > > >On Sun, Apr 04, 2010 at 09:56:01PM -0700, Jim Wigginton wrote: > >>I was thinking about SSH URI's some and I think it'd be neat if the > >>draft for SSH URI's supported tunneling and exec style channel > >>requests. eg. > >> > >>ssh://user@host.example.com/exec:ls%20-la > >> > >>...or... > >> > >>ssh://user@host.example.com/tunnel:www.google.com:80 > >> > >>As is, the only thing that SSH URI's, as defined in the draft > >>(draft-ietf-secsh-scp-sftp-ssh-uri-04), really support, it seems, are > >>retrieving files via SFTP and opening interactive shells. And > >>although that, I suppose, has its uses, I think SSH URI's could be > >>made a lot more versatile by adding support for the above. > > > >Good point. But where should we stop? > > A URI should identify a resource. That is, it should identify some > particular object or service, such as an interactive shell, a file > in SFTP (arguably this should be a distinct URI scheme), or some > other subsystem. It does not need to and probably should not be > capable of expressing configuration of parameters that control how > we talk to the ssh server, such as algorithm selection. Is an interactive shell an identifiable resource? IMO, that's borderline, but because it'd be useful I think it should be supported. > IMHO... > > - We _do_ want to be able to specify a username, and yes, even a password. Yes to the first, grumble to the latter. > - We _do_ want to be able to have URI's that refer to interactive > shells, if only because this is the "main" service SSH provides. Yes, but do we want to specify that a pty is needed? To me that follows client context and isn't part of the resource being identified. Alternatively: indicate in the URI that a terminal is required in order to access the resource. > - We _do_ want to be able to have URI's that refer to connections > to arbitrary subsystems. Some subsystems may be more useful to access > in this way than others. Yes. > - We _do_ want to be able to have URI's that refer to specific files > accessed via SFTP. However, this probably wants to be a separate > URI scheme. Yes, and yes. > - We _do_ want to be able to have URI's that establish tunnels which > allow the SSH client to connect to services on the SSH server's network. Yes. > - We do _not_ want to be able to have URI's that establish tunnels which > allow the SSH server to connect to services on the SSH client's network. Maybe. See below. > - We do _not_ want URI's to be able to express preferences for algorithm > selection in any form. This would amount to allowing the provider of a > URI to override the client's security policy, which is a bad idea. I don't agree with the rationale: client local security policy should always trump whatever's in the URI. The ability to specify algs in the URI does not make that necessarily untrue. But I agree with the sentiment (after all, the client and server can and will negotiate; attempting to preempt the negotiation won't). > - A user agent may wish to restrict what userauth methods can be used, > based on its ability to handle user interaction or on local security > policy. In fact, we probably should offer advice about taking care > with the use of non-interactive authentication methods, lest an attacker > trick a user into issuing a command to some service. How can you use, say, pubkey userauth to "trick a user into issuing a command to some service" other than the service identified by the URI? > - In a similar vein, probably we should not allow SSH URI's that direct > the user to execute a particular command on a remote SSH server. That > sounds exceedingly dangerous. I tend to agree with this and the "no local port forwardings", but also think that client UIs can take care of warning the user, or even outright fobidding access to such URIs. Having a way to name an arbitrary remote command execution could be useful in some contexts. However, if it were so useful that most users would disable the warnings, then I think we'd be better off not specifying a way to create such URIs in the first place. > - And, an SSH URI should not be able to control behaviors like agent > forwarding, which again are a matter of client security policy and > should not be subject to override. Yes. This was the gist of my initial reply. Nico -- From karynnd@stanford.edu Mon Apr 19 10:42:52 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3873A6B1F for ; Mon, 19 Apr 2010 10:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_GOOD_DAY=0.679, US_DOLLARS_3=0.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjYlvRlEYjXs for ; Mon, 19 Apr 2010 10:42:52 -0700 (PDT) Received: from smtp.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) by core3.amsl.com (Postfix) with ESMTP id 7635B3A6B29 for ; Mon, 19 Apr 2010 10:37:21 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BC7B017938C; Mon, 19 Apr 2010 10:37:12 -0700 (PDT) Received: from zm02.stanford.edu (zm02.Stanford.EDU [171.67.219.152]) by smtp.stanford.edu (Postfix) with ESMTP id ED86F17934A; Mon, 19 Apr 2010 10:35:47 -0700 (PDT) Date: Mon, 19 Apr 2010 10:35:47 -0700 (PDT) From: Liu Tai Ling Reply-To: Liu Tai Ling Message-ID: <533984984.223881271698547965.JavaMail.root@zm02.stanford.edu> Subject: Good Day MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [212.116.219.150] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (zclient/5.0.21_GA_3150.RHEL4_64) X-Authenticated-User: karynnd@stanford.edu To: undisclosed-recipients:; Good Day, I have a Business Proposal of $21,300,000.00 for you to handle with me from my bank.please contact me on {lingtai25@yahoo.com.hk} with your Full names,occupation,private phone number,current residential address. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 19 17:49:17 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96EA93A63C9 for ; Mon, 19 Apr 2010 17:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w2m6WCHPpGa for ; Mon, 19 Apr 2010 17:49:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 6D26B3A67B4 for ; Mon, 19 Apr 2010 17:49:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A61B663B1AD; Tue, 20 Apr 2010 00:48:59 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 5AD5663B1CF for ; Tue, 20 Apr 2010 00:48:57 +0000 (UTC) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o3JMx0On002826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2010 18:59:00 -0400 (EDT) Date: Mon, 19 Apr 2010 18:59:00 -0400 From: Jeffrey Hutzelman To: Simon Tatham , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: tunneling and exec channel request support for SSH URIs Message-ID: <10D2943B6906E9AA06EDFBE4@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, April 14, 2010 11:04:26 AM +0100 Simon Tatham wrote: > Jeffrey Hutzelman wrote: >> - We _do_ want to be able to have URI's that refer to connections >> to arbitrary subsystems. Some subsystems may be more useful to access >> in this way than others. > [...] >> - [...] probably we should not allow SSH URI's that direct >> the user to execute a particular command on a remote SSH server. That >> sounds exceedingly dangerous. > > I'm unconvinced that these two points are really consistent with > each other. If I want to set up a custom service on a given SSH > server, I might find it inconvenient to invent a new subsystem name, > or to set up a special account whose shell is the service program, > so I might prefer to provide service users with a command to run. > Drawing a hard dividing line between "subsystem" and "exec" seems > like the wrong answer to me. > The real danger is URIs which combine a specific command with the > user's _personal_ credentials. There's no danger in 'ssh to this > specialist service machine, log in as specialist-service, and run > specialist-service-command', but there is danger in 'ssh to this > server you had an account on anyway, implicitly log in as yourself > due to already having an SSH agent active and the URI not specifying > a username to override your own, and run "rm -rf *"'. So perhaps the > right answer is to constrain both command and general-subsystem > specifications to the case in which full authentication credentials > (e.g. username _and_ password) are also provided in the URI _and > authentication with those credentials succeeds_? Yes, I think that's closer to the mark. On the other hand, I do think it should be possible to write a URI that refers to an SFTP service accessed using the user's credentials. I suppose to make this determination for a subsystem, one needs to know what the subsystem does, which suggets that such cases require a separate URI scheme or at least further specification beyond the scope of the present document. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 20 02:31:20 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F48B28C10C for ; Tue, 20 Apr 2010 02:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOr3OJXMIy5N for ; Tue, 20 Apr 2010 02:31:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BAE153A6907 for ; Tue, 20 Apr 2010 02:30:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1D51E63B176; Tue, 20 Apr 2010 09:30:40 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 6B2DC63B16B for ; Tue, 20 Apr 2010 09:30:37 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CE52F40008; Tue, 20 Apr 2010 11:30:34 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id C1EE940073; Tue, 20 Apr 2010 11:30:34 +0200 (CEST) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id A1F6F40008; Tue, 20 Apr 2010 11:30:34 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id o3K9UY1x022659; Tue, 20 Apr 2010 11:30:34 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id o3K9UXSQ022658; Tue, 20 Apr 2010 11:30:33 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Jeffrey Hutzelman Cc: Simon Tatham , ietf-ssh@NetBSD.org Subject: Re: tunneling and exec channel request support for SSH URIs References: <10D2943B6906E9AA06EDFBE4@minbar.fac.cs.cmu.edu> Date: Tue, 20 Apr 2010 11:30:33 +0200 In-Reply-To: <10D2943B6906E9AA06EDFBE4@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 19 Apr 2010 18:59:00 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman writes: > --On Wednesday, April 14, 2010 11:04:26 AM +0100 Simon Tatham > wrote: >> The real danger is URIs which combine a specific command with the >> user's _personal_ credentials. > Yes, I think that's closer to the mark. On the other hand, I do think > it should be possible to write a URI that refers to an SFTP service > accessed using the user's credentials. I think the relevant distinction is that we don't want URI:s that specify *destructive* operations using the user's credentials. Creating an interactive shell is not destructive (unless the user's login shell is set to something interesting), and reading a file over sftp also is not. But executing a command may or may not be destructive. And there's no easy way to make the distinction (like GET vs POST in HTTP, if only people were using them the right way...). I haven't made up my mind on ssh uri:s (and the topic is on the periphery of my personal interests), but it seems the safest option is to not have URIs specifying execution of commands at all. Specifying an uri to start an arbitrary subsystem may still be ok. It is different from executing a command, if we are willing to assume that merely *starting* the subsystem does not imply any destructive operations, just like for starting an interactive shell. To actually *do* somthing using that subsystem should most likely use a separate uri scheme. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 20 03:03:24 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F7828C149 for ; Tue, 20 Apr 2010 03:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.647 X-Spam-Level: X-Spam-Status: No, score=-4.647 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+sGhyQ34Xhw for ; Tue, 20 Apr 2010 03:03:23 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4E25D28C233 for ; Tue, 20 Apr 2010 02:46:30 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1C4E663B185; Tue, 20 Apr 2010 09:46:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id E10A663B159 for ; Tue, 20 Apr 2010 09:46:13 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1O4A1y-0001o9-E3; Tue, 20 Apr 2010 10:46:10 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: <10D2943B6906E9AA06EDFBE4@minbar.fac.cs.cmu.edu> To: ietf-ssh@NetBSD.org Cc: Jeffrey Hutzelman Subject: Re: tunneling and exec channel request support for SSH URIs MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 20 Apr 2010 10:46:10 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman wrote: > Yes, I think that's closer to the mark. On the other hand, I do think it > should be possible to write a URI that refers to an SFTP service accessed > using the user's credentials. I suppose to make this determination for a > subsystem, one needs to know what the subsystem does, Yes. SFTP could reasonably be an exception to the general principle I suggested, based on specific knowledge that SFTP in particular is a subsystem which won't do anything destructive just from being invoked - it would have to be specifically instructed by the user to delete or modify files for anything dangerous to occur. But really, an SFTP URI and an SSH URI citing subsystem "sftp" are not semantically the same anyway. The latter, if it is to be treated consistently with URIs citing a command, merely tells a basic SSH client what exec/subsystem request to send, so that the user would be presented with raw access to the SFTP service, which isn't very useful at all. The former also indicates that a different client program (or the same client program in a different mode, according to taste) should be run, so that the user gets a thing that looks like a filesystem browser. -- Simon Tatham "The difference between theory and practice is that, in theory, there is no difference." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 26 04:31:16 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFFF3A6B8F for ; Mon, 26 Apr 2010 04:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-4rlsRqEa76 for ; Mon, 26 Apr 2010 04:31:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 679CA3A6B8C for ; Mon, 26 Apr 2010 04:30:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8A24163B10F; Mon, 26 Apr 2010 11:30:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "yxa-v.extundo.com", Issuer "CAcert Class 3 Root" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 458C763B10C for ; Mon, 26 Apr 2010 11:30:30 +0000 (UTC) Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3QANQZQ013345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Apr 2010 12:23:30 +0200 From: Simon Josefsson To: Satoru Kanno Cc: ietf-ssh@netbsd.org, cfrg@irtf.org, kanda.masayuki@lab.ntt.co.jp Subject: Re: Call for Review on draft-kanno-secsh-camellia-00 References: <4BD55CE3.4020706@po.ntts.co.jp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100426:kanno.satoru@po.ntts.co.jp::j/L2+yFHjRCV5qBz:0hGB X-Hashcash: 1:22:100426:ietf-ssh@netbsd.org::UpXOCakPNTdEZVZG:5TsI X-Hashcash: 1:22:100426:kanda.masayuki@lab.ntt.co.jp::mLASYFAJxZ1+fJl6:5evx X-Hashcash: 1:22:100426:cfrg@irtf.org::3KrokdKRzW6weF/C:Ncd7 Date: Mon, 26 Apr 2010 12:23:26 +0200 In-Reply-To: <4BD55CE3.4020706@po.ntts.co.jp> (Satoru Kanno's message of "Mon, 26 Apr 2010 18:29:07 +0900") Message-ID: <871ve2h5r5.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Satoru Kanno writes: > Dear List, > > We have submitted draft of Camellia for secure shell as an individual > draft, because we found the Camellia patch for OpenSSH. > > Camellia draft: > http://www.ietf.org/id/draft-kanno-secsh-camellia-00.txt > Camellia patch: > https://bugzilla.mindrot.org/show_bug.cgi?id=1340 > > Comments about our document would be welcome. Thanks for writing the document. My comments: 1) As you know, Camellia is patented by your organization, and you need to file a patent disclosure to the IETF. The earlier disclosures related to Camellia are not relevant: they don't permit use for Secure Shell. 2) It is not possible to implement your document without also reading RFC 5646, thus I believe that document has to be a normative reference. Alternatively, you could duplicate the necessary text. /Simon From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 26 15:32:34 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274823A68C3 for ; Mon, 26 Apr 2010 15:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqXs3GMXlwjl for ; Mon, 26 Apr 2010 15:32:33 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 003823A66B4 for ; Mon, 26 Apr 2010 15:32:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2D40A63B17E; Mon, 26 Apr 2010 22:32:13 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.jpl.nasa.gov", Issuer "VeriSign Class 3 Secure Server CA - G2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 9E77F63B17D for ; Mon, 26 Apr 2010 22:32:11 +0000 (UTC) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3QLJK4A025071; Mon, 26 Apr 2010 14:19:21 -0700 Subject: Re: [Cfrg] Call for Review on draft-kanno-secsh-camellia-00 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <871ve2h5r5.fsf@mocca.josefsson.org> Date: Mon, 26 Apr 2010 14:19:19 -0700 Cc: Satoru Kanno , "cfrg@irtf.org" , "kanda.masayuki@lab.ntt.co.jp" , "ietf-ssh@netbsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BD55CE3.4020706@po.ntts.co.jp> <871ve2h5r5.fsf@mocca.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1078) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I also note that if ssh implements gssapi-keyex then ssh can use = Camellia if Kerberos implements Camellia. In other words, this draft is = not strictly necessary (though it may be desirable). On Apr 26, 2010, at 3:23 AM, Simon Josefsson wrote: > Satoru Kanno writes: >=20 >> Dear List, >>=20 >> We have submitted draft of Camellia for secure shell as an individual >> draft, because we found the Camellia patch for OpenSSH. >>=20 >> Camellia draft: >> http://www.ietf.org/id/draft-kanno-secsh-camellia-00.txt >> Camellia patch: >> https://bugzilla.mindrot.org/show_bug.cgi?id=3D1340 >>=20 >> Comments about our document would be welcome. >=20 > Thanks for writing the document. My comments: >=20 > 1) As you know, Camellia is patented by your organization, and you = need > to file a patent disclosure to the IETF. The earlier disclosures > related to Camellia are not relevant: they don't permit use for Secure > Shell. >=20 > 2) It is not possible to implement your document without also reading > RFC 5646, thus I believe that document has to be a normative = reference. > Alternatively, you could duplicate the necessary text. >=20 > /Simon > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 26 16:11:24 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CCF13A6BF2 for ; Mon, 26 Apr 2010 16:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBUmze3i+iqY for ; Mon, 26 Apr 2010 16:11:24 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C31FC3A6BF1 for ; Mon, 26 Apr 2010 16:10:59 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6147063B181; Mon, 26 Apr 2010 23:10:42 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet14.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id D3EBF63B182 for ; Mon, 26 Apr 2010 23:10:39 +0000 (UTC) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by rcsinet14.oracle.com (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id o3QNAcsu004062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 26 Apr 2010 23:10:39 GMT Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3QNA9Y6017032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Apr 2010 23:10:11 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3QNA4OD019408; Mon, 26 Apr 2010 23:10:05 GMT Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 191522721272323345; Mon, 26 Apr 2010 16:09:05 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Apr 2010 16:09:04 -0700 Date: Mon, 26 Apr 2010 18:08:59 -0500 From: Nicolas Williams To: "Henry B. Hotz" Cc: Simon Josefsson , Satoru Kanno , "cfrg@irtf.org" , "kanda.masayuki@lab.ntt.co.jp" , "ietf-ssh@netbsd.org" Subject: Re: [Cfrg] Call for Review on draft-kanno-secsh-camellia-00 Message-ID: <20100426230859.GH10389@Sun.COM> References: <4BD55CE3.4020706@po.ntts.co.jp> <871ve2h5r5.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090201.4BD61D54.00F6:SCFMA4539811,ss=1,fgs=0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Mon, Apr 26, 2010 at 02:19:19PM -0700, Henry B. Hotz wrote: > I also note that if ssh implements gssapi-keyex then ssh can use > Camellia if Kerberos implements Camellia. In other words, this draft > is not strictly necessary (though it may be desirable). Not really. SSHv2 uses the GSS-API only for authentication (and, effectively, channel binding of authentication to key exchange), not for transport portection. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 26 17:11:14 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4073A6C0B for ; Mon, 26 Apr 2010 17:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M74r+YkLkQGH for ; Mon, 26 Apr 2010 17:11:13 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 86A4F3A6C11 for ; Mon, 26 Apr 2010 17:11:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6693363B18B; Tue, 27 Apr 2010 00:10:52 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by mail.netbsd.org (Postfix) with ESMTP id E969363B17A for ; Tue, 27 Apr 2010 00:10:49 +0000 (UTC) Received: from [92.1.142.139] ([92.1.142.139] helo=[192.168.0.20] country=GB ident=simon*pop3$sxw&org^uk) by v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4bd61761.6d99.22; Mon, 26 Apr 2010 23:44:49 +0100 (envelope-sender ) Subject: Re: [Cfrg] Call for Review on draft-kanno-secsh-camellia-00 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Simon Wilkinson In-Reply-To: Date: Mon, 26 Apr 2010 23:44:48 +0100 Cc: Simon Josefsson , Satoru Kanno , "cfrg@irtf.org" , "kanda.masayuki@lab.ntt.co.jp" , "ietf-ssh@netbsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BD55CE3.4020706@po.ntts.co.jp> <871ve2h5r5.fsf@mocca.josefsson.org> To: Henry B. Hotz X-Mailer: Apple Mail (2.1078) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 26 Apr 2010, at 22:19, Henry B. Hotz wrote: > I also note that if ssh implements gssapi-keyex then ssh can use = Camellia if Kerberos implements Camellia. In other words, this draft is = not strictly necessary (though it may be desirable). gssapi-keyex only authenticates the initial connection handshake. It = isn't involved at all in encryption of the ssh session. S. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 27 11:09:35 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6673A6A89 for ; Tue, 27 Apr 2010 11:09:35 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char E1 hex): From: "Kov\341cs" P."J\341nos" <[...] X-Spam-Flag: NO X-Spam-Score: 1.888 X-Spam-Level: * X-Spam-Status: No, score=1.888 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, SUBJECT_NEEDS_ENCODING=0.001, SUBJ_ILLEGAL_CHARS=1.586] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhXFL9pUqwfY for ; Tue, 27 Apr 2010 11:09:34 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 6549F3A6B95 for ; Tue, 27 Apr 2010 11:09:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CDBB763B116; Tue, 27 Apr 2010 18:08:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from kissez893.easyvserver.com (kissez893.easyvserver.com [62.233.81.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "plesk", Issuer "plesk" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 3A55C63B12A for ; Tue, 27 Apr 2010 18:08:51 +0000 (UTC) Received: (qmail 5752 invoked by uid 48); 27 Apr 2010 18:02:40 +0100 Message-ID: <20100427170239.5738.qmail@kissez893.easyvserver.com> Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 2.117 (F2.74) Date: Tue, 27 Apr 2010 17:02:39 UT From: "Kovács" P."János" To: Ietf Ssh Subject: Önnek is kettö van Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Tisztelt Ietf Ssh ! Optimista ember lévén talán már értesült róla, hogy idén a non-profit szervezetek az életben maradásukért küzdenek, így nagyon fontos, hogy rendelkezzen adója mindkét 1%-áról. Amennyiben elfogadja ajánlásomat kérem, jelezze és már küldöm is a két szervezet adatát (adószám ill. tech.szám), amik több mint 12 éve azon munkálkodnak, hogy lássuk és tapasztaljuk van kiút a nehézből, és nem kell önpusztító életet élni, ahhoz hogy pillanatra boldogok legyünk. Köszönettel, legyen szép és derűs a napja! Kovács P. János u.i: Amennyiben zavartam levelemmel, kérem jelezze számomra. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 27 13:05:02 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616063A6A06 for ; Tue, 27 Apr 2010 13:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.417 X-Spam-Level: ** X-Spam-Status: No, score=2.417 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pdGk-s1wXBu for ; Tue, 27 Apr 2010 13:05:01 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 040AE3A69B6 for ; Tue, 27 Apr 2010 13:05:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9B3B663B16E; Tue, 27 Apr 2010 20:04:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B405A63B103; Tue, 27 Apr 2010 20:04:38 +0000 (UTC) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by mail.netbsd.org (Postfix) with ESMTP id 254F263B10C for ; Mon, 26 Apr 2010 09:30:13 +0000 (UTC) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.13.4/NTTSOFT) with ESMTP id o3Q9U5Hf014501; Mon, 26 Apr 2010 18:30:05 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id o3Q9U5Bw011997; Mon, 26 Apr 2010 18:30:05 +0900 (JST) Received: from ccmds35.silk.ntts.co.jp [10.107.0.35] by sadoku34.silk.ntts.co.jp with SMTP id UAA11996; Mon, 26 Apr 2010 18:30:05 +0900 Received: from mail127.silk.ntts.co.jp (ccmds35.ntts.co.jp [127.0.0.1]) by ccmds35.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id o3Q9U4j2000685; Mon, 26 Apr 2010 18:30:04 +0900 Received: from mail127.silk.ntts.co.jp (localhost [127.0.0.1]) by mail127.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id o3Q9U5EE015323; Mon, 26 Apr 2010 18:30:05 +0900 (JST) Received: from ccmds35 (ccmds35.silk.ntts.co.jp [10.107.0.35]) by mail127.silk.ntts.co.jp (8.14.3/NTTSOFT) with SMTP id o3Q9U4we015320; Mon, 26 Apr 2010 18:30:04 +0900 (JST) Message-ID: <4BD55CE3.4020706@po.ntts.co.jp> Date: Mon, 26 Apr 2010 18:29:07 +0900 From: Satoru Kanno User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ietf-ssh@netbsd.org, cfrg@irtf.org CC: kanda.masayuki@lab.ntt.co.jp Subject: Call for Review on draft-kanno-secsh-camellia-00 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.2-Client X-CC-Mail-RelayStamp: CC-Mail-V4.2-Server Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Dear List, We have submitted draft of Camellia for secure shell as an individual draft, because we found the Camellia patch for OpenSSH. Camellia draft: http://www.ietf.org/id/draft-kanno-secsh-camellia-00.txt Camellia patch: https://bugzilla.mindrot.org/show_bug.cgi?id=1340 Comments about our document would be welcome. Best regards, Satoru ---------------------------------------------------------------------- Filename: draft-kanno-secsh-camellia Revision: 00 Title: The Camellia for the Secure Shell Transport Layer Protocol Creation_date: 2010-04-26 WG ID: Independent Submission Number_of_pages: 10 Abstract: Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to specify the Camellia cipher as symmetric encryption algorithm for the SSH Transport Layer Protocol. The IETF Secretariat. ------------------------------------------------------------------------ -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno.satoru@po.ntts.co.jp