From stefan@aaa-sec.com Thu May 5 06:45:01 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE3AE06A6 for ; Thu, 5 May 2011 06:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j25sVvYepICk for ; Thu, 5 May 2011 06:45:00 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCA5E0593 for ; Thu, 5 May 2011 06:44:59 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 273323F6381 for ; Thu, 5 May 2011 15:42:47 +0200 (CEST) Received: (qmail 34127 invoked from network); 5 May 2011 13:42:41 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 May 2011 13:42:41 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 05 May 2011 15:42:37 +0200 From: Stefan Santesson To: Nico Williams , Message-ID: Thread-Topic: [saag] W3C Identity paper on GSS-REST In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [saag] W3C Identity paper on GSS-REST X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 13:45:01 -0000 Nico, I find this document and proposal very interesting and I believe that it would be very useful in the context of HTTP authentication. I see many "home cooked" solutions for user authentication over http and not all of them turned out to be as secure as intended, especially not in the context of channel binding and resilience against MitM attacks. At the same time, many of these non standard authentication techniques are driven by different reasons and needs, requiring different solutions. A generic model for GSS based authentication over HTTP could be very useful in many of those cases and could help avoid security pitfalls. /Stefan On 11-04-28 3:05 AM, "Nico Williams" wrote: >I wrote the attached paper in a hurry, as I hadn't realized the >deadline was upon me. Even so, I think it will be of interest to >SAAGers. > >The abstract: > > Applications often require context-specific authentication > decisions, particularly HTTP applications. TLS provides limited > authentication facilities, and only at the transport-layer, which > is often inconvenient. GSS-REST is a method that obtains > pluggable application-layer authentication for HTTP-based > applications, using off-the-shelf authentication mechanisms and > without replacing TLS for transport protection. Additionally, > GSS-REST provides a method by which to get away from cookies. > > GSS-REST, as its name indicates, consists of POSTing GSS-API > "security context tokens" to a resource in order to authenticate > the client user and the service and to exchange cryptographic key > material, the latter needed only optionally to strengthen cookies. > > Additionally, we discus some aspects of identity selection UI > issues. > >Nico >-- >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nico@cryptonector.com Thu May 5 07:27:41 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC72E08AE for ; Thu, 5 May 2011 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO2ICIVJZBmH for ; Thu, 5 May 2011 07:27:40 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id E4BC8E06A6 for ; Thu, 5 May 2011 07:27:40 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 8686C2C806D for ; Thu, 5 May 2011 07:27:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=lvXjUOcksSDHGly1UMm8F KkebzFfrlmlr6K0PRWBRLNVsmGUGife1WBa0I/MxMpuj8um79mU85Ro6vshr66/u 9KO2lAowkcB/eF8QfopHZL8ZRBQSfkciUy1lghSdPpB92hxeNsJZ4TrMkVeXLYtY wYbgDvHzcFMXqov+6MKRQE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=E+wCcMQLLjaqf1bSBsTf +Cv4spg=; b=PKvUcUDKNnnD2XgDivcKeUQBze0QzYiDelaZVZRBbq1vLnkp1QXt bio6XxFugc2Crq9Dq3vSGGOx2X3kltwNCjbXQNCflniqqn0poLVrQr1t9BLzDNMW I/Hnfkb3E9LZ+1LGJANXsXPCOH5p12ifitQphqo0oBPHclyEmwjjneI= Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 65E1F2C806B for ; Thu, 5 May 2011 07:27:40 -0700 (PDT) Received: by qyk7 with SMTP id 7so1621430qyk.10 for ; Thu, 05 May 2011 07:27:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.178.33 with SMTP id cv1mr668096vdc.277.1304605659607; Thu, 05 May 2011 07:27:39 -0700 (PDT) Received: by 10.52.155.4 with HTTP; Thu, 5 May 2011 07:27:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 May 2011 09:27:39 -0500 Message-ID: From: Nico Williams To: Stefan Santesson Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] W3C Identity paper on GSS-REST X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 14:27:41 -0000 Stefan, Thanks for the feedback! My goal in pushing the use of a framework is to make it easier to use integrate application-layer authentication and identity into the browser -- there's no way to do that with app "home grown" authentication methods. Nico -- From turners@ieca.com Sun May 8 09:31:45 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2A4E06D5 for ; Sun, 8 May 2011 09:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhwvjJIsSZH5 for ; Sun, 8 May 2011 09:31:44 -0700 (PDT) Received: from nm3.bullet.mail.sp2.yahoo.com (nm3.bullet.mail.sp2.yahoo.com [98.139.91.73]) by ietfa.amsl.com (Postfix) with SMTP id 42633E06BE for ; Sun, 8 May 2011 09:31:44 -0700 (PDT) Received: from [98.139.91.61] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 08 May 2011 16:31:43 -0000 Received: from [98.139.91.32] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 08 May 2011 16:31:43 -0000 Received: from [127.0.0.1] by omp1032.mail.sp2.yahoo.com with NNFMP; 08 May 2011 16:31:43 -0000 X-Yahoo-Newman-Id: 955912.47987.bm@omp1032.mail.sp2.yahoo.com Received: (qmail 74674 invoked from network); 8 May 2011 16:31:43 -0000 Received: from thunderfish.local (turners@96.231.117.210 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 08 May 2011 09:31:43 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: djH0UQwVM1lzPh4zkFzd0VJAbbLb.5eFGpJirjiUShfsyDm SfFX4VpHMkCf4jBne7qSqdABelN8WZ0hCL1QRpm.unouU_raBMQ5JwEzExYz GORpKSnW..Rzuooy.t9.Ho4uL3UFckMDJbrZDdGecJZMkjVS2r4NpuyOpI1G 7gHNwQYfOLkKBkQwMT.E.GfONJKL21BA2ax1wPCsxd7okBA7g4ZcmOyws8CR 8.uqKS3gdRMB0pWGClUfjy9tXVeyWD4c5vG941orntnMjCsnTmGPh8Ce5_aY tj8ZQdp0Z.ew6MUclhHk5Fm7bWvoIq9YHq37KGG18fOuimjwbRuJO8D7WcAt p8vKZTM3UTYh_0GSyGUcD_oWqTfYd7p4VvTwXk5uelOduaDJBcAHReyGJch9 UwrhDEqfDusWhSK_ydhGDU1kUN_y1IvERB_KbE3Wf5uA04D4PIA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DC6C56D.6040709@ieca.com> Date: Sun, 08 May 2011 12:31:41 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 16:31:45 -0000 The authors of the following draft have asked that I forward this to saag for comment: https://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/ They also noted that there's a Usenix Security paper and video: http://tcpcrypt.org/docs.php Please direct discussion to tsv-area@ietf.org. Cheers, spt From housley@vigilsec.com Mon May 9 07:20:43 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C801E075C for ; Mon, 9 May 2011 07:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.257 X-Spam-Level: X-Spam-Status: No, score=-101.257 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgDPRFlxdhvk for ; Mon, 9 May 2011 07:20:42 -0700 (PDT) Received: from odin.smetech.net (unknown [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2D186E0754 for ; Mon, 9 May 2011 07:20:42 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id BCDA2F2417E; Mon, 9 May 2011 10:20:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id PMTqkkqz55hN; Mon, 9 May 2011 10:20:30 -0400 (EDT) Received: from [192.168.2.100] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7B953F2417C; Mon, 9 May 2011 10:20:45 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-8-226125876 Date: Mon, 9 May 2011 10:20:40 -0400 References: To: IETF SAAG , IRTF CFRG Message-Id: <4FFC6A90-0871-4E05-B7B0-62D2C1AC0A91@vigilsec.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [saag] Fwd: NIST Requests Comments on Two Draft Publications X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 14:20:43 -0000 --Apple-Mail-8-226125876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 These documents may be of interest to people on these mail lists. Russ >=20 > From: "Caswell, Sara Johnson" > Date: May 9, 2011 10:11:27 AM EDT > To: "housley@vigilsec.com" > Subject: NIST Requests Comments on Two Draft Publications >=20 > *** PLEASE DO NOT REPLY TO THIS EMAIL *** >=20 > =20 >=20 > NIST requests comments on the draft revisions of two publications: = NIST Special Publication (SP) 800-57, Part 1 and SP 800-90A. > =20 > The revision of SP 800-57, Part 1, Recommendation for Key Management: = Part 1: General, is intended to align the document with SP 800-131A, as = well as to provide a general update of the document, including = references to NIST publications that have been completed since the last = revision of the document. A general list of the changes is provided at = the end of Appendix D, and except for some editorial changes, the = changes within the documented are marked. The document is available at = http://csrc.nist.gov/publications/PubsDrafts.html. Please send comments = to KeyManagement@nist.gov by July 1, 2011, with =93SP 800-57, Part 1 = comments=94 in the subject line. > =20 > SP 800-90A, Recommendation for Random Number Generation Using = Deterministic Random Bit Generators, is intended as a revision of the = currently-posted version of SP 800-90. Two of the appendices in SP = 800-90 provided information on entropy sources and RBG constructions. = These topics will be discussed in further detail in SP 800-90B and SP = 800-90C, respectively, which are under development. SP 800-90A takes = into account the work on RBGs that has been conducted within Accredited = Standards Committee X9 since the original publication of SP 800-90. A = general list of the changes is provided at the end of Appendix H, and = except for some editorial changes, the changes within the document are = marked. The document is available at = http://csrc.nist.gov/publications/PubsDrafts.html. Please send comments = to RBG_comments@nist.gov by August 1, 2011, with =93SP 800-90A comments=94= in the subject line. >=20 --Apple-Mail-8-226125876 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 These = documents may be of interest to people on these mail = lists.

Russ



From: "Caswell, Sara Johnson" <sara.caswell@nist.gov>
Date: May 9, 2011 10:11:27 AM EDT
Subject: NIST Requests = Comments on Two Draft Publications

*** PLEASE DO NOT REPLY TO THIS EMAIL ***

 

NIST requests comments on the draft revisions of two = publications: NIST Special Publication (SP) 800-57, Part 1 and SP 800-90A.
 
The revision of SP 800-57, Part = 1, Recommendation for Key Management: Part 1: = General, is intended to align the document with SP 800-131A, as well as to = provide a general update of the document, including references to NIST = publications that have been completed since the last revision of the document. A general = list of the changes is provided at the end of Appendix D, and except for some = editorial changes, the changes within the documented are marked. The document is available at http://csrc.ni= st.gov/publications/PubsDrafts.html. Please send comments to KeyManagement@nist.gov by = July 1, = 2011, with =93SP 800-57, Part 1 comments=94 in the subject line.
 
SP 800-90A, = Recommendation for Random Number Generation Using Deterministic Random Bit = Generators, is intended as a revision of the currently-posted version of SP 800-90. = Two of the appendices in SP 800-90 provided information on entropy sources and = RBG constructions. These topics will be discussed in further detail in SP = 800-90B and SP 800-90C, respectively, which are under development. SP 800-90A = takes into account the work on RBGs that has been conducted within Accredited Standards Committee X9 since the original publication of SP 800-90. A = general list of the changes is provided at the end of Appendix H, and except for = some editorial changes, the changes within the document are marked. The = document is available at http://csrc.ni= st.gov/publications/PubsDrafts.html. Please send comments to RBG_comments@nist.gov by = August 1, = 2011, with =93SP 800-90A comments=94 in the subject line.


= --Apple-Mail-8-226125876-- From paul.hoffman@vpnc.org Mon May 9 12:39:40 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89835E0743 for ; Mon, 9 May 2011 12:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.908 X-Spam-Level: X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY7VbmFH8bPQ for ; Mon, 9 May 2011 12:39:39 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EEE35E072F for ; Mon, 9 May 2011 12:39:38 -0700 (PDT) Received: from sn83.proper.com (sn83.proper.com [75.101.18.83]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p49JdavU010835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 May 2011 12:39:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: multipart/alternative; boundary=Apple-Mail-1-245262024 Date: Mon, 9 May 2011 12:39:36 -0700 References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: saag@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [saag] Fwd: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:39:40 -0000 --Apple-Mail-1-245262024 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Of interest to some here. > From: Eran Hammer-Lahav > Date: May 9, 2011 12:22:23 PM PDT > To: "apps-discuss@ietf.org" > Cc: Ben Adida , "http-state@ietf.org" = , OAuth WG , "'Adam Barth = \(adam@adambarth.com\)'" , HTTP Working Group = > Subject: [apps-discuss] HTTP MAC Authentication Scheme >=20 > (Please discuss this draft on the Apps-Discuss = mailing list) > =20 > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > =20 > The draft includes: > =20 > * An HTTP authentication scheme using a MAC algorithm to authenticate = requests (via a pre-arranged MAC key). > * An extension to the Set-Cookie header, providing a method for = associating a MAC key with a session cookie. > * An OAuth 2.0 binding, providing a method of returning MAC = credentials as an access token. > =20 > Some background: OAuth 1.0 introduced an HTTP authentication scheme = using HMAC for authenticating an HTTP request with partial cryptographic = protection of the HTTP request (namely, the request URI, host, and = port). The OAuth 1.0 scheme was designed for delegation-based use cases, = but is widely =93abused=94 for simple client-server authentication (the = poorly named =91two-legged=92 use case). This functionality has been = separated from OAuth 2.0 and has been reintroduced as a standalone, = generally applicable HTTP authentication scheme called MAC. > =20 > Comments and feedback is greatly appreciated. > =20 > EHL --Apple-Mail-1-245262024 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Of = interest to some here.

From: Eran Hammer-Lahav = <eran@hueniverse.com>
=
Date: May 9, 2011 = 12:22:23 PM PDT
Cc: Ben Adida <ben@adida.net>, "http-state@ietf.org" <http-state@ietf.org>, OAuth = WG <oauth@ietf.org>, "'Adam = Barth \(adam@adambarth.com\)'" <adam@adambarth.com>, HTTP = Working Group <ietf-http-wg@w3.org>
=
Subject: [apps-discuss] = HTTP MAC Authentication Scheme

(Please discuss this draft on = the Apps-Discuss < 
X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB6BE06D3; Tue, 10 May 2011 00:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.071 X-Spam-Level: X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBLvTXe-VBGV; Tue, 10 May 2011 00:28:30 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 19740E06A1; Tue, 10 May 2011 00:28:30 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by hapkido.dreamhost.com (Postfix) with ESMTP id 7512E178990; Tue, 10 May 2011 00:28:29 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 064F5B8058; Tue, 10 May 2011 00:28:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=mk92Z5DDkEJUF9xkCvze64aL7T8wf8h+YUUx4RAouVgy y4ESqIeR2EaPmWBtEppc/3kY+eSnUme7d2Nuo41t0wyHk1XvevVcWBUZISitPDaf C1JADsoCLJBcdOJrobDcIOTdVW+ApYoWlWVUyKKXNMjphc5/Og5SQqVfHelwRhY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=OoMbxSARWjURs+gW+89BLptMRlk=; b=T+fUhi8BOOU sbQDLdwJNt2jL+5Wx1K6Svfzk1TTtS/Ysd+HNb4biEeKObzAgz5nPVZIzlMgpWLK mt3kPMBXYOQ0itdrU9pArVN1Hl+XgjbiSgRxuUrMB0B/a9xOF65rG9xpKX0CPXzf iLE0v0U/Xvow09DY3/zLMZCyqNes3gYc= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id BB7B6B8057; Tue, 10 May 2011 00:28:28 -0700 (PDT) Received: by vws12 with SMTP id 12so391320vws.31 for ; Tue, 10 May 2011 00:28:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.199 with SMTP id cc7mr571378vdc.197.1305012508190; Tue, 10 May 2011 00:28:28 -0700 (PDT) Received: by 10.52.155.4 with HTTP; Tue, 10 May 2011 00:28:28 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA9EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA9EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 10 May 2011 02:28:28 -0500 Message-ID: From: Nico Williams To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "saag@ietf.org" , Apps Discuss Subject: Re: [saag] [apps-discuss] Fwd: HTTP MAC Authentication Scheme X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 07:28:31 -0000 On Tue, May 10, 2011 at 2:06 AM, Eran Hammer-Lahav wr= ote: >> "What is your threat model?" > > An eavesdropper grabbing plaintext credentials and using them to gain acc= ess to protected resources. That's 99% of it, with the other 1% being that = sending plaintext credentials over TLS can still leak due to incorrect impl= ementation, or attacks on dynamic configuration, leading the client to send= its plaintext credentials over TLS to the wrong server. That's what I thought. If you add channel binding (meaning, to make it real simple: add the server's certificate, or hash thereof, to the MAC inputs -- the server cert is available in at least some JavaScript implementations, like Firefox's) then you'll avoid those attacks that you mention when using TLS. It's not clear to me if you want to allow use of this MAC without using TLS. From the above I guess so, since the MAC alone will take care of the eavesdroppers. Nico -- From Jeff.Hodges@KingsMountain.com Tue May 10 14:05:17 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F84E0749 for ; Tue, 10 May 2011 14:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.455 X-Spam-Level: X-Spam-Status: No, score=-100.455 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrZYipRLvifk for ; Tue, 10 May 2011 14:05:15 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 65DA2E06DB for ; Tue, 10 May 2011 14:05:12 -0700 (PDT) Received: (qmail 31502 invoked by uid 0); 10 May 2011 20:58:32 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 10 May 2011 20:58:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Zm3nRI+NGXwxUqReNc676aYdT0A97WpmsTTUfJMiDOraUmCodqA++vK+rkVEhcHDUBtgUtWMuUU/+jy8l8dwGuuwyeUWOR5+le5nr+duW0vGD7T7t8lG2SGo2Zm9Qj+t; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.83]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QJu0l-0004iJ-TX for saag@ietf.org; Tue, 10 May 2011 14:58:32 -0600 Message-ID: <4DC9A6F6.9020803@KingsMountain.com> Date: Tue, 10 May 2011 13:58:30 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [saag] fyi: Combating Cybercrime: Principles, Policies, and Programs X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 21:05:17 -0000 Hi, You might be interested in the whitepaper and corresponding blog post we just published: "Combating Cybercrime: Principles, Policies, and Programs". https://www.thepaypalblog.com/2011/05/combating-cybercrime/ The whitepaper is linked at the bottom of the post and can also be found here: https://www.paypal-media.com/assets/pdf/fact_sheet/PayPal_CombatingCybercrime_WP_0411_v4.pdf While we don't believe we have all of the answers to combating crime online, we do believe we've presented a set of principles as well as several workable policy and technology options that will help make progress against this problem. Please do let us know your thoughts (via myself is fine), and feel free to forward this message as appropriate. thanks, =JeffH From mcgrew@cisco.com Tue May 10 16:04:03 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7D7E06DC; Tue, 10 May 2011 16:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrusk3EDEa05; Tue, 10 May 2011 16:04:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E0BF8E06CE; Tue, 10 May 2011 16:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=5014; q=dns/txt; s=iport; t=1305068640; x=1306278240; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=91PYmIY2f99aexEEb78LhybT9j0oOcNZR9TB+/uBEUw=; b=eIEoMX6DUjAawpRwIvGJryGRwcsoN2fOwN7nk2c6cgl5l44vwLgznd0I /ExYzZNJq0iZVCnuTf/u1RWcELH/8ZeyE0ki5bw6KP8Na6hOT/Em6dHYU Esv2Ks1X6UlY1mxVhUexxeMaAUQoIj1oq5ub4VzA0OS5QoXqAVUpKLSVL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJLDyU2rRDoH/2dsb2JhbACmDHeIcB2gH54khg8EhkKGVoJWjixV X-IronPort-AV: E=Sophos;i="4.64,348,1301875200"; d="scan'208";a="695212342" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 10 May 2011 23:04:00 +0000 Received: from stealth-10-32-254-213.cisco.com (stealth-10-32-254-213.cisco.com [10.32.254.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4AN3wvw029465; Tue, 10 May 2011 23:03:59 GMT Message-Id: From: David McGrew To: sqs@cs.stanford.edu, dm@uun.org, M.Handley@cs.ucl.ac.uk, mike@shiftleft.org, dabo@cs.stanford.edu, bittau@cs.stanford.edu In-Reply-To: <4DC6C56D.6040709@ieca.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 May 2011 16:03:58 -0700 References: <4DC6C56D.6040709@ieca.com> X-Mailer: Apple Mail (2.936) Cc: tsv-area@ietf.org, saag@ietf.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 23:04:03 -0000 Hello Tcpcrypt authors, I have skimmed the internet draft and the USENIX Security paper on tcpcrypt, and while it is interesting and thought-provoking work, I have a hard time understanding what the goals of the I-D are relative to the TCP standard. The draft says "Standards Track"; would Experimental be more appropriate? It mentions the following objectives: "Tcpcrypt maintains the confidentiality of data transmitted in TCP segments against a passive eavesdropper. It can be used to protect already established TCP connections against denial-of-service attacks involving injection of forged RST segments or desynchronizing of sequence numbers." Yes, but TLS and IPsec perform the former function, and IPsec and TCP-AO perform the latter. In addition, running TCP over DTLS would also accomplishes the latter function; this practice is done in some (so-called) SSLVPNs. "Finally, applications that perform authentication can obtain end-to- end confidentiality and integrity guarantees by tying authentication to tcpcrypt Session ID values." This seems like a potentially useful feature, though it seems similar to channel binding (RFCs 5056 and 5929). "Tcpcrypt is designed to require relatively low overhead, particularly at servers, so as to be useful even in the case of servers accepting many TCP connections per second." The idea of batching signatures seems like a useful contribution that could be put to good use by servers that are under heavy loads. But why not implement this idea in a way that could be used by multiple applications and protocols? It should not be hard to define a format for digital signatures that carries a few extra hash values, and allows a verifying party to check the signature on the message that they care about, while ignoring the rest. The idea of reversing the client/server association between RSA encryption/decryption is a pragmatic way to help out servers, though it is tied to a specific algorithm (the results would be quite different for ECDH or ECDSA, say). Both of those performance optimizations are definitely interesting, but I don't understand why the best way utilize those ideas would be through a new cryptographic protocol within the TCP layer. I also have some comments on some other points. The USENIX Security paper mentions the goal of ubiquitous encryption (though the draft does not). Requiring changes to the TCP stack would hinder deployment and work against the goal of ubiquity. The draft describes the RSA public keys as "ephemeral", and the companion paper says that the protocol achieves forward secrecy. However, if it was really the case that a new RSA keypair was generated for each exchange, then the performance would be significantly worse than what is shown in the paper, because the cost of that operation is significantly higher than that of RSA decryption. I think the claims and/or guidance to implementers needs to be clarified. The Security Considerations section looks like boilerplate, while it seems that there is a lot to be discussed, such as the security properties of Session IDs. Is it possible to relate the protocol to a previously analyzed protocol? It is similar to ISO/IEC 11770-3, in that it relies on public key encryption of nonces, without signatures. Perhaps there is some analysis of that protocol, or of a protocol with cryptosuite negotiation, that could be leveraged. The companion paper does have a brief analysis of the security of the protocol, but it would be good if it were possible to benefit from detailed analyses of all aspects of protocol security. (I do realize that the analysis is made easier by the relative simplicity of the protocol; that's a good thing.) The security analysis defines the parameter "k ~ 256 is the minimum of the min-entropy of a public key". Surely that doesn't match the 2048- bit RSA examples in the paper? As a side note, I am surprised to see a proposal to add so much cryptographic functionality into the TCP standard, considering that not many years have passed since the transport area declined to add (much simpler) key transport functionality into TCP in support of TCP- AO. Perhaps "Experimental" was intended, or perhaps I have missed or misunderstood some aspect of this work. regards, David On May 8, 2011, at 9:31 AM, Sean Turner wrote: > The authors of the following draft have asked that I forward this to > saag for comment: > > https://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/ > > They also noted that there's a Usenix Security paper and video: > http://tcpcrypt.org/docs.php > > Please direct discussion to tsv-area@ietf.org. > > Cheers, > > spt > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From pgut001@login01.cs.auckland.ac.nz Tue May 10 19:42:29 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F675E06CE; Tue, 10 May 2011 19:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sCta0UaGldZ; Tue, 10 May 2011 19:42:29 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 81E33E06A2; Tue, 10 May 2011 19:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1305081749; x=1336617749; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20bittau@cs.stanford.edu,=20dabo@cs.stanford.edu,=20 dm@uun.org,=0D=0A=20=20=20=20M.Handley@cs.ucl.ac.uk,=20mc grew@cisco.com,=20mike@shiftleft.org,=0D=0A=20=20=20=20sq s@cs.stanford.edu|Subject:=20Re:=20[saag]=20fyi:=20tcpcry pt=20draft|Cc:=20saag@ietf.org,=20tsv-area@ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2011=20May=202011=2014:42:17=20+ 1200; bh=6YEtBbses3elp0oh4Q3yTR6z2ks7Bx/pQTawO5qR418=; b=ej04mArL+HimjpDLfjbRyog0NFALWw9UjYsrBEVk/s/0gYSTndNla2iO /XZjWvvnS0iADtRD7vi0uEeofOUPU39dLknxvS/hx3Fib1W7p8tS2OAkL hP4SYLFkPC3l9x7ylBZFxct5PPIKiwVRfY+TAmHB8H76zLwgtL6FJN95E 0=; X-IronPort-AV: E=Sophos;i="4.64,350,1301832000"; d="scan'208";a="61179905" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 May 2011 14:42:17 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QJzNR-0004LB-HT; Wed, 11 May 2011 14:42:17 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QJzNR-0007S1-Bu; Wed, 11 May 2011 14:42:17 +1200 From: Peter Gutmann To: bittau@cs.stanford.edu, dabo@cs.stanford.edu, dm@uun.org, M.Handley@cs.ucl.ac.uk, mcgrew@cisco.com, mike@shiftleft.org, sqs@cs.stanford.edu In-Reply-To: Message-Id: Date: Wed, 11 May 2011 14:42:17 +1200 Cc: tsv-area@ietf.org, saag@ietf.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 02:42:29 -0000 David McGrew writes: >I have a hard time understanding what the goals of the I-D are relative to >the TCP standard. The draft says "Standards Track"; would Experimental be >more appropriate? +1. I've got it set aside for next week when I may have a bit more time to look at it, but my first reaction was "why?". I understand it's always fun to dream up a new crypto protocol (Ferguson and Schneier wrote a whole book on it), but... why? It definitely seems like an Experimental to me, not Standards-track. Peter. From nico@cryptonector.com Tue May 10 19:59:22 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319ACE06A6; Tue, 10 May 2011 19:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M5ZR1rH2lpR; Tue, 10 May 2011 19:59:21 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id A8B02E065D; Tue, 10 May 2011 19:59:21 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 6CB99778061; Tue, 10 May 2011 19:59:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=GzgNoh5DK+YfgxzrQKZakylzONimZ1obIWQyNh6UooLZ Vb0eLjL24IQPvyjLkDckOPGEjKJBME8AK9R6rJJtXH5uP7CTAiFbBuugWlPbc8eD xJjWSZkcakFQr0QvygP1ugGroACyOQSGVaqfou+cHrAKe9P3vUq9jbexsnOruCo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=j49Vg80nUmssmqW2THvpZa3wzg8=; b=jPXSdI1xIag hqCkgnNvZoeKNXq5dM/+iFw3F7CFraJJbB0fA2A7oCRmu5Ig0o3JWYHY3HPW8a4z FQ42NNlBhA2a2nsT460/GQFXIFUljz2AJWDZq3MZd73DMVHy4Uo6m0xepbJmlaQ1 DULE5/pxamASKBRCuyhM5tioKlZsE3QA= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 2ED7F77805F; Tue, 10 May 2011 19:59:21 -0700 (PDT) Received: by vws12 with SMTP id 12so66827vws.31 for ; Tue, 10 May 2011 19:59:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.168 with SMTP id x8mr261161vdt.77.1305082760511; Tue, 10 May 2011 19:59:20 -0700 (PDT) Received: by 10.52.155.4 with HTTP; Tue, 10 May 2011 19:59:20 -0700 (PDT) In-Reply-To: References: <4DC6C56D.6040709@ieca.com> Date: Tue, 10 May 2011 21:59:20 -0500 Message-ID: From: Nico Williams To: David McGrew Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dabo@cs.stanford.edu, dm@uun.org, bittau@cs.stanford.edu, sqs@cs.stanford.edu, tsv-area@ietf.org, saag@ietf.org, mike@shiftleft.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 02:59:22 -0000 On Tue, May 10, 2011 at 6:03 PM, David McGrew wrote: > "Finally, applications that perform authentication can obtain end-to-end > confidentiality and integrity guarantees by tying authentication to tcpcr= ypt > Session ID values." =C2=A0This seems like a potentially useful feature, t= hough it > seems similar to channel binding (RFCs 5056 and 5929). That's exactly what it would, well, depending on the security properties of those session ID values. I would prefer that the channel binding data for tcpcrypt be derived as a keyed PRF taken over the key exchange messages, with the key being derived from the session key. This approach has the benefit of strongly binding the entire negotiation (e.g., of algorithms, ...) and also being defined independently of the key exchange algorithm (which is nice because you propose using key transport, but I can imagine that some will want key agreement). I'll review the I-D in detail later. Nico -- From lars.eggert@nokia.com Tue May 3 05:56:44 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CEFE081A for ; Tue, 3 May 2011 05:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.68 X-Spam-Level: X-Spam-Status: No, score=-103.68 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599, GB_I_INVITATION=-2, SARE_NETPROD=0.111, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Zpo6zTtuveW for ; Tue, 3 May 2011 05:56:43 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 57332E0813 for ; Tue, 3 May 2011 05:56:43 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p43Cufi7019715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 May 2011 15:56:42 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-5--297315713; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 3 May 2011 15:56:38 +0300 Message-Id: <13CA844C-3E76-481A-9E72-8FD248E5A863@nokia.com> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.fit.nokia.com); Tue, 03 May 2011 15:56:38 +0300 (EEST) X-Nokia-AV: Clean X-Mailman-Approved-At: Wed, 11 May 2011 08:14:01 -0700 Subject: [saag] FIVE DAYS REMAINING: Call for Nominations: Applied Networking Research Prize (ANRP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: anrp@isoc.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:56:44 -0000 --Apple-Mail-5--297315713 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) *** Apply until May 8, 2011 for the ANR Prize for IETF-81, *** July 24-29, 2011 in Quebec City, Canada! The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recently published results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize (ANRP) is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: * cash prize of $500 (USD) * invited talk at the IRTF Open Meeting * travel grant to attend the week-long IETF meeting (airfare, hotel, registration, stipend) * recognition at the IETF plenary * invitation to related social activities * potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize (ANRP) will be awarded three times per year, in conjunction with the three annual IETF meetings. HOW TO APPLY Applicants must nominate a peer-reviewed, recently-published, original journal, conference or workshop paper. Both self nominations (nominating one's own paper) and third-party nominations (nominating someone else's paper) are encouraged. The nominee must be one of the main authors of the nominated paper. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how presentation of these research results will foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party applications) are available to attend the respective IETF meeting in person and in its entirety. Applications must include: * the name and email address of the nominee * a reference to the published nominated paper * a PDF copy of the nominated paper * a statement that describes how the nominated paper fulfills the goals of the award * a statement that the nominee is available to attend the respective IETF meeting in person and in its entirety * a brief biography or CV of the nominee * optionally, any other supporting information (link to nominee's web site, etc.) *** Applications are submitted by email to anrp@isoc.org. *** SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. The goal is to select 1-2 submissions for the Applied Networking Research Prize (ANRP) during each application period. All applicants will be notified by email. IMPORTANT DATES Applications open: April 11, 2011 Applications close: May 8, 2011 Notifications: May 31, 2011 IETF-81 Meeting: July 24-29, 2011 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). --Apple-Mail-5--297315713 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzEyNTYzOVowIwYJKoZIhvcNAQkE MRYEFPLcZ5efbqmVD5+pSer8A1CSrfEzMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ALI7zenAQ3IMxytc27tZJs5Xk4Nxh7kdOd/dOAmsg7C1c8ttrVFNLUl2oF5suXKUtTqYgXHqsj2o UoEupxrOKKFZRh98OLuNw7b5k6Kpm8f30HjNc06UrP6/2X1HoPVy3pmAtibHfBpZ2o82MRIcJDig u9woGECJtf3vvYuvTyRV8Rjh+noKRgp30FsXAuInHwMVuGOqtnvnBkPpu3JEiCMFao6oRItCO2Qw qja87g6+tUd81bVJm+i96Si8Sbr4XDHth4z8QwbtAnwQvagd+8zgvD7k8TTnkIWkFUtCNDYf5F2z /OIo4RKW2tBY/C43w6l+qEZwCF4ZHohM38U612sAAAAAAAA= --Apple-Mail-5--297315713-- From steve@shinkuro.com Mon May 9 09:41:04 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC752E0891 for ; Mon, 9 May 2011 09:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0fR+dnd+t-D for ; Mon, 9 May 2011 09:41:04 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 67DD0E0889 for ; Mon, 9 May 2011 09:40:47 -0700 (PDT) Received: from [66.92.164.104] (HELO dynamic125.shinkuro.com) by execdsl.com (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 19603982; Mon, 09 May 2011 15:41:41 +0000 From: Steve Crocker Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-51-230931036 Date: Mon, 9 May 2011 11:40:45 -0400 In-Reply-To: <4FFC6A90-0871-4E05-B7B0-62D2C1AC0A91@vigilsec.com> To: IETF SAAG , IRTF CFRG References: <4FFC6A90-0871-4E05-B7B0-62D2C1AC0A91@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 11 May 2011 08:14:01 -0700 Subject: Re: [saag] Fwd: NIST Requests Comments on Two Draft Publications X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:41:04 -0000 --Apple-Mail-51-230931036 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I did a quick scan to see if these documents reference RFC 4086, = Randomness Requirements for Security, or otherwise deal with the = challenge of finding sources of entropy without using a hardware device = specifically designed for the purpose. I didn't see any such reference, = but I may not have read carefully enough. I would be grateful if someone can explain whether the NIST documents = are supposed to cover software implementations of randomness. If so, = are the relevant references included? If not, then I'm curious how = these publications fit into the larger framework of providing advice to = implementors, including those implementors who are building software = distributions of key generators that have to run on platforms that do = not have explicit and specific sources of entropy. Thanks, Steve Crocker On May 9, 2011, at 10:20 AM, Russ Housley wrote: > These documents may be of interest to people on these mail lists. >=20 > Russ >=20 >=20 >>=20 >> From: "Caswell, Sara Johnson" >> Date: May 9, 2011 10:11:27 AM EDT >> To: "housley@vigilsec.com" >> Subject: NIST Requests Comments on Two Draft Publications >>=20 >> *** PLEASE DO NOT REPLY TO THIS EMAIL *** >>=20 >> =20 >>=20 >> NIST requests comments on the draft revisions of two publications: = NIST Special Publication (SP) 800-57, Part 1 and SP 800-90A. >> =20 >> The revision of SP 800-57, Part 1, Recommendation for Key Management: = Part 1: General, is intended to align the document with SP 800-131A, as = well as to provide a general update of the document, including = references to NIST publications that have been completed since the last = revision of the document. A general list of the changes is provided at = the end of Appendix D, and except for some editorial changes, the = changes within the documented are marked. The document is available at = http://csrc.nist.gov/publications/PubsDrafts.html. Please send comments = to KeyManagement@nist.gov by July 1, 2011, with =93SP 800-57, Part 1 = comments=94 in the subject line. >> =20 >> SP 800-90A, Recommendation for Random Number Generation Using = Deterministic Random Bit Generators, is intended as a revision of the = currently-posted version of SP 800-90. Two of the appendices in SP = 800-90 provided information on entropy sources and RBG constructions. = These topics will be discussed in further detail in SP 800-90B and SP = 800-90C, respectively, which are under development. SP 800-90A takes = into account the work on RBGs that has been conducted within Accredited = Standards Committee X9 since the original publication of SP 800-90. A = general list of the changes is provided at the end of Appendix H, and = except for some editorial changes, the changes within the document are = marked. The document is available at = http://csrc.nist.gov/publications/PubsDrafts.html. Please send comments = to RBG_comments@nist.gov by August 1, 2011, with =93SP 800-90A comments=94= in the subject line. >>=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-51-230931036 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I did = a quick scan to see if these documents reference RFC 4086, Randomness = Requirements for Security, or otherwise deal with the challenge of = finding sources of entropy without using a hardware = device specifically designed for the purpose.  I didn't = see any such reference, but I may not have read carefully = enough.

I would be grateful if someone can explain = whether the NIST documents are supposed to cover software = implementations of randomness.  If so, are the relevant references = included?  If not, then I'm curious how these publications fit into = the larger framework of providing advice to implementors, including = those implementors who are building software distributions of key = generators that have to run on platforms that do not have explicit and = specific sources of = entropy.

Thanks,

Steve = Crocker



On May 9, = 2011, at 10:20 AM, Russ Housley wrote:

These documents may be of = interest to people on these mail = lists.

Russ



From: "Caswell, Sara Johnson" <sara.caswell@nist.gov>
Date: May 9, 2011 10:11:27 AM EDT
Subject: NIST Requests = Comments on Two Draft Publications

*** PLEASE DO NOT REPLY TO THIS EMAIL ***

 

NIST requests comments on the draft revisions of two = publications: NIST Special Publication (SP) 800-57, Part 1 and SP 800-90A.
 
The revision of SP 800-57, Part = 1, Recommendation for Key Management: Part 1: = General, is intended to align the document with SP 800-131A, as well as to = provide a general update of the document, including references to NIST = publications that have been completed since the last revision of the document. A general = list of the changes is provided at the end of Appendix D, and except for some = editorial changes, the changes within the documented are marked. The document is available at http://csrc.ni= st.gov/publications/PubsDrafts.html. Please send comments to KeyManagement@nist.gov by = July 1, = 2011, with =93SP 800-57, Part 1 comments=94 in the subject line.
 
SP 800-90A, = Recommendation for Random Number Generation Using Deterministic Random Bit = Generators, is intended as a revision of the currently-posted version of SP 800-90. = Two of the appendices in SP 800-90 provided information on entropy sources and = RBG constructions. These topics will be discussed in further detail in SP = 800-90B and SP 800-90C, respectively, which are under development. SP 800-90A = takes into account the work on RBGs that has been conducted within Accredited Standards Committee X9 since the original publication of SP 800-90. A = general list of the changes is provided at the end of Appendix H, and except for = some editorial changes, the changes within the document are marked. The = document is available at http://csrc.ni= st.gov/publications/PubsDrafts.html. Please send comments to RBG_comments@nist.gov by = August 1, = 2011, with =93SP 800-90A comments=94 in the subject line.

=

_______________________________________= ________
saag mailing list
saag@ietf.org
https://www.ietf.org/ma= ilman/listinfo/saag

= --Apple-Mail-51-230931036-- From eran@hueniverse.com Tue May 10 00:06:33 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701A7E07F2 for ; Tue, 10 May 2011 00:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb68ZiTFj3Pk for ; Tue, 10 May 2011 00:06:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D6EB5E0827 for ; Tue, 10 May 2011 00:06:32 -0700 (PDT) Received: (qmail 3056 invoked from network); 10 May 2011 07:06:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2011 07:06:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 10 May 2011 00:06:27 -0700 From: Eran Hammer-Lahav To: Nico Williams Date: Tue, 10 May 2011 00:06:22 -0700 Thread-Topic: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme Thread-Index: AcwO3dwSAJ0GFgZeSi2aLK8HDXFhZgAAkNug Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA9EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 May 2011 08:14:01 -0700 Cc: "saag@ietf.org" , Apps Discuss Subject: Re: [saag] [apps-discuss] Fwd: HTTP MAC Authentication Scheme X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 07:06:33 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmljbyBXaWxsaWFtcyBb bWFpbHRvOm5pY29AY3J5cHRvbmVjdG9yLmNvbV0NCj4gU2VudDogTW9uZGF5LCBNYXkgMDksIDIw MTEgMTE6NDYgUE0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2DQo+IENjOiBBcHBzIERpc2N1c3M7 IHNhYWdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFtzYWFnXSBGd2Q6 IEhUVFAgTUFDIEF1dGhlbnRpY2F0aW9uIFNjaGVtZQ0KPiANCj4gT24gTW9uLCBNYXkgOSwgMjAx MSBhdCAzOjI5IFBNLCBFcmFuIEhhbW1lci1MYWhhdg0KPiA8ZXJhbkBodWVuaXZlcnNlLmNvbT4g d3JvdGU6DQo+ID4+IFJlZ2FyZGluZyB0aGUgcXVlc3Rpb24gb2Ygd2hlbiB0byBpbmNsdWRlIGEg aGFzaCBvZiB0aGUgYm9keSBpbiB0aGUNCj4gPj4gbm9ybWFsaXplZCByZXF1ZXN0IHN0cmluZyB0 aGF0IGdldHMgTUFDZWQuLi4gSWYgb25lIGlzIHVzaW5nIFRMUywNCj4gPj4gdGhlbiBJIHN1Z2dl c3QgYWRkaW5nIHRoZSBUTFMgY2hhbm5lbCBiaW5kaW5nIGludG8gdGhlIE1BQyBpbnB1dA0KPiA+ PiBzdHJpbmcgYW5kIGRyb3AgdGhlIGJvZHkgaGFzaC4gwqBUaGlzIHdpbGwgc3BlZWQgdXAgb3Bl cmF0aW9uLCBzaW5jZQ0KPiA+PiB0aGVyZSdzIG5vIG5lZWQgdG8gaGFzaCB0aGUgYm9keSAodGhp bmsgb2YgdGhlIHBlcmZvcm1hbmNlIGltcGFjdCBvZg0KPiA+PiBoYXNoaW5nIHRoZSByZXF1ZXN0 IGJvZHkgaW4gYW4gaW1wbGVtZW50YXRpb24gdGhhdCB1c2VzIHNlbmRmaWxlKCkhKS4NCj4gPg0K PiA+IEl0IGlzIHN0aWxsIG5vdCBjbGVhciB3aGVuIGhhc2hpbmcgdGhlIGJvZHkgaXMgcmVhbGx5 IGltcG9ydGFudCwgYW5kIGlmIHRoaXMNCj4gc2hvdWxkIGJlIGp1c3QgYW4gb3B0aW9uYWwgZmVh dHVyZSBvciBzb21ldGhpbmcgdGhhdCBpcyByZXF1aXJlZC4gSWYgaXQgaXMNCj4gb3B0aW9uYWws IGl0IGlzIG5vdCBjbGVhciBob3cgdGhlIHNlcnZlciBzaG91bGQgaW5kaWNhdGUgdG8gdGhlIGNs aWVudCB0aGF0IGl0IGlzDQo+IHJlcXVpcmVkIGZvciBhbnkgcGFydGljdWxhciBwcm90ZWN0ZWQg cmVzb3VyY2UuIFdlJ3JlIHN0aWxsIGRlYmF0aW5nIHRoYXQgYW5kDQo+IHdhaXRpbmcgZm9yIHNv bWUgZGVwbG95bWVudCBleHBlcmllbmNlIHRvIGd1aWRlIHVzLg0KPiANCj4gU2VlIGJlbG93Lg0K PiANCj4gPj4gSSBkb24ndCBzZWUgdGhlIHBvaW50IG9mIGF0dGVtcHRpbmcgdG8gcHJvdmlkZSBv bmx5IHBhcnRpYWwgaW50ZWdyaXR5DQo+ID4+IHByb3RlY3Rpb24gKGUuZy4sIHRoZSBkcmFmdCBk b2Vzbid0IHNheSB0byBpbmNsdWRlIGV2ZXIgcmVxdWVzdA0KPiA+PiBoZWFkZXIgaW50byB0aGUg TUFDDQo+ID4+IGlucHV0KSBpZiB0aGVyZSdzIG5vIFRMUy4gwqBJbiBmYWN0LCBJIGRvbid0IHNl ZSB0aGUgcG9pbnQgb2Ygbm90DQo+ID4+IHVzaW5nIFRMUywgYnV0IGlmIFRMUyBhdm9pZGFuY2Ug aXMgZGVzaXJlZCB0aGVuIGFsbCBvZiB0aGUgcmVxdWVzdA0KPiA+PiAobWludXMgdGhlIE1BQykg YW5kIHJlc3BvbnNlIHNob3VsZCBiZSBjb3ZlcmVkIGJ5IHRoZSBNQUMuDQo+ID4NCj4gPiBUaGUg cG9pbnQgaXMgdG8gYmUgcHJhY3RpY2FsIGdpdmVuIHRoZSB0YXJnZXQgYXVkaWVuY2UgYW5kIHVz ZSBjYXNlcyB3ZSBoYXZlDQo+IGZvciB0aGlzOiB3ZWIgZGV2ZWxvcGVycy4NCj4gDQo+IFN1cmVs eSBub3QuICBTdXJlbHkgdGhlIHBvaW50IGlzIHRvIG1ha2Ugc29tZSBhdHRhY2sgbW9yZSBkaWZm aWN1bHQuDQo+IFllcywgc3VyZWx5IGl0J3MgbmljZSB0byBtYWtlIGl0IGVhc3kgZm9yIGRldmVs b3BlcnMgdG8gdXNlIGl0LCBidXQgdGhhdCdzIGENCj4gc2Vjb25kYXJ5IGlzc3VlLiAgVGhlIHBy aW1hcnkgaXNzdWUsIHdoYXQgSSdtIG5vdCBnZXR0aW5nIGZyb20gdGhlIEktRCwgaXMNCj4gd2hh dCB5b3UncmUgdHJ5aW5nIHRvIHByb3RlY3QgYWdhaW5zdC4NCj4gDQo+ICJXaGF0IGlzIHlvdXIg dGhyZWF0IG1vZGVsPyINCg0KQW4gZWF2ZXNkcm9wcGVyIGdyYWJiaW5nIHBsYWludGV4dCBjcmVk ZW50aWFscyBhbmQgdXNpbmcgdGhlbSB0byBnYWluIGFjY2VzcyB0byBwcm90ZWN0ZWQgcmVzb3Vy Y2VzLiBUaGF0J3MgOTklIG9mIGl0LCB3aXRoIHRoZSBvdGhlciAxJSBiZWluZyB0aGF0IHNlbmRp bmcgcGxhaW50ZXh0IGNyZWRlbnRpYWxzIG92ZXIgVExTIGNhbiBzdGlsbCBsZWFrIGR1ZSB0byBp bmNvcnJlY3QgaW1wbGVtZW50YXRpb24sIG9yIGF0dGFja3Mgb24gZHluYW1pYyBjb25maWd1cmF0 aW9uLCBsZWFkaW5nIHRoZSBjbGllbnQgdG8gc2VuZCBpdHMgcGxhaW50ZXh0IGNyZWRlbnRpYWxz IG92ZXIgVExTIHRvIHRoZSB3cm9uZyBzZXJ2ZXIuDQoNCkVITA0KDQoNCg0K From nico@cryptonector.com Tue May 10 20:00:43 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E48CE06CE; Tue, 10 May 2011 20:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4erPs2DmySP; Tue, 10 May 2011 20:00:43 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8EFE065D; Tue, 10 May 2011 20:00:43 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 156E11B4059; Tue, 10 May 2011 20:00:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=eaylnnDa1y/wrA7gjWSGbQeL0Z7rugX/Kum9GUGLX1vp 9iYeojl//T5vXSB2zPVpfxHF5bi0but/Xgypd6bDPrvQjz0Jgww4wDc/rNofbkcW TlewdKW/1aqcC1vb2JfK18o0IwacxeZebObK8mZArsxn+RQRWa00EotZlCsK/vo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=UvtTAFclcddJuAe6/uguyak2bFU=; b=jqA0b3SUPtA c1YHYRLThCai5zi+3sNCEveRXRUYZ8hVHclUEMHF1DBSH1OqKblC88nqBUHJqAcl WuQKh94LytWShd3g0K2X59vrKUliF4hRP0XI3p++iz//l8q8w6eMIw8l+zEoVBap 79VwB+geFvcsox3liPxz5aH5aR44Pn3k= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id CB9C01B4058; Tue, 10 May 2011 20:00:42 -0700 (PDT) Received: by vxg33 with SMTP id 33so65716vxg.31 for ; Tue, 10 May 2011 20:00:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.170 with SMTP id m10mr2729820vdv.160.1305082842253; Tue, 10 May 2011 20:00:42 -0700 (PDT) Received: by 10.52.155.4 with HTTP; Tue, 10 May 2011 20:00:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 May 2011 22:00:42 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 11 May 2011 08:14:01 -0700 Cc: dabo@cs.stanford.edu, dm@uun.org, bittau@cs.stanford.edu, sqs@cs.stanford.edu, tsv-area@ietf.org, saag@ietf.org, mike@shiftleft.org Subject: Re: [saag] fyi: tcpcrypt draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 03:00:43 -0000 On Tue, May 10, 2011 at 9:42 PM, Peter Gutmann wrote: > David McGrew writes: > >>I have a hard time understanding what the goals of the I-D are relative t= o >>the TCP standard. =C2=A0The draft says "Standards Track"; would Experimen= tal be >>more appropriate? > > +1. =C2=A0I've got it set aside for next week when I may have a bit more = time to > look at it, but my first reaction was "why?". =C2=A0I understand it's alw= ays fun to > dream up a new crypto protocol (Ferguson and Schneier wrote a whole book = on > it), but... why? =C2=A0It definitely seems like an Experimental to me, no= t > Standards-track. Most likely because someone's thinking of putting this on silicon. Sure, there's IPsec, but then you'd need to implement RFC5660 if you want similar semantics, and no one has yet. Nico -- From kwatsen@juniper.net Thu May 12 16:35:11 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E61E067C for ; Thu, 12 May 2011 16:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f2iaLNSlDHe for ; Thu, 12 May 2011 16:35:10 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id E1B93E066E for ; Thu, 12 May 2011 16:35:07 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTcxuqzivZeioLETyuKngd0lR4BULRP/z@postini.com; Thu, 12 May 2011 16:35:10 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 12 May 2011 16:31:04 -0700 From: Kent Watsen To: "saag@ietf.org" , "ietf-ssh@NetBSD.org" Date: Thu, 12 May 2011 16:31:02 -0700 Thread-Topic: draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwQ/KfZsPkIbzpDSPSTwl+b7uFoaA== Message-ID: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 23:35:11 -0000 Since the SECSH working group has concluded, the Security Area Directors, S= ean and Stephen, recommended posting an announcement regarding this individ= ual submission to the SAAG and IETF-SSH mailing lists. =20 http://tools.ietf.org/html/draft-kwatsen-reverse-ssh-00 Abstract This memo presents a technique for a SSH (Secure Shell) server to initiate the underlying TCP connection to the SSH client. This role reversal is necessary in cases where the SSH client would otherwise be unable to initiate an SSH connection to the SSH server, such as a device "calling home" on its first boot. I come from the NETCONF and NETMOD working groups, and this submission has = been developed primarily to support NETCONF, though it's applicable to any = SSH-based protocol and actually has little to do with NETCONF at all, which= is why it is brought here for your consideration. FWIW, Juniper has implemented a variant of this proposal, called "outbound-= ssh", on almost all its platforms for nearly 5 years now. The solution pre= sented in this I-D, being fully transparent to the SSH protocol, has been s= hown to be easy to implement across various operating systems and programmi= ng languages. PS: I just subscribed to both the SAAG and IETF-SSH lists - cheers! Thanks, Kent -- Kent Watsen JSBU/DBU Architect Juniper Networks From touch@isi.edu Thu May 12 17:38:01 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D34E06F1 for ; Thu, 12 May 2011 17:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.91 X-Spam-Level: X-Spam-Status: No, score=-104.91 tagged_above=-999 required=5 tests=[AWL=1.689, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+vEf7ot-nep for ; Thu, 12 May 2011 17:37:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 903C7E065A for ; Thu, 12 May 2011 17:37:58 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p4D0baL8008945 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 12 May 2011 17:37:36 -0700 (PDT) Message-ID: <4DCC7D50.9080308@isi.edu> Date: Thu, 12 May 2011 17:37:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 00:38:01 -0000 On 5/12/2011 4:31 PM, Kent Watsen wrote: > > Since the SECSH working group has concluded, the Security Area Directors, Sean and Stephen, recommended posting an announcement regarding this individual submission to the SAAG and IETF-SSH mailing lists. > > > http://tools.ietf.org/html/draft-kwatsen-reverse-ssh-00 > > Abstract > > This memo presents a technique for a SSH (Secure Shell) server to > initiate the underlying TCP connection to the SSH client. This role > reversal is necessary in cases where the SSH client would otherwise > be unable to initiate an SSH connection to the SSH server, such as a > device "calling home" on its first boot. > > > I come from the NETCONF and NETMOD working groups, and this > submissionhas been developed primarily to support NETCONF, though > it's applicable to any SSH-based protocol and actually has little to > do with NETCONF at all, which is why it is brought here for your > consideration. > > FWIW, Juniper has implemented a variant of this proposal, called "outbound-ssh", on almost all its platforms for nearly 5 years now. The solution presented in this I-D, being fully transparent to the SSH protocol, has been shown to be easy to implement across various operating systems and programming languages. Any clue what port they're using for this? There doesn't appear to be one currently allocated. Also, there are separate ports for SSH (22) and netconf over SSH (830) - does this mean this proposal would need a reverse port for every SSH-based service? Joe From kwatsen@juniper.net Thu May 12 18:01:38 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F11413000C for ; Thu, 12 May 2011 18:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX3rKtwWU6OI for ; Thu, 12 May 2011 18:01:37 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6AE07B8 for ; Thu, 12 May 2011 18:01:36 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTcyC5kR2kT/ryRa88eYyj8KoUViB+Kmf@postini.com; Thu, 12 May 2011 18:01:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 12 May 2011 18:01:08 -0700 From: Kent Watsen To: Joe Touch Date: Thu, 12 May 2011 18:01:03 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwRCT2XJ6PSpkunTnGaX8Meag/D4g== Message-ID: References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> In-Reply-To: <4DCC7D50.9080308@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 01:01:38 -0000 DQoNCkFueSBjbHVlIHdoYXQgcG9ydCB0aGV5J3JlIHVzaW5nIGZvciB0aGlzPyBUaGVyZSBkb2Vz bid0IGFwcGVhciB0byBiZQ0Kb25lIGN1cnJlbnRseSBhbGxvY2F0ZWQuDQoNCkp1bmlwZXIgaXMg dXNpbmcgcG9ydCA3MTA0LCBJIHRoaW5rLCBidXQgdGhlcmUgaXMgbm8gbmVlZCB0byBtYWludGFp biB0aGF0IGNvbXBhdGliaWxpdHkgc2luY2UgdGhlIG1lc3NhZ2UgZm9ybWF0IHByZXNlbnRlZCBp biB0aGlzIHN1Ym1pc3Npb24gaXMgbm90IGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCB0aGVpcidz LiAgRm9yIGluc3RhbmNlLCBKdW5pcGVyJ3MgZXhpc3RpbmcgZm9ybWF0IG9ubHkgc3VwcG9ydHMg b25lIGhvc3Qta2V5LCB3aGVyZWFzIHRoaXMgdGhpcyBwcm9wb3NhbCBzdXBwb3J0cyBhbGwgdGhl IGhvc3Qta2V5cyB0aGUgU1NIIHNlcnZlciBoYXMuDQoNCg0KQWxzbywgdGhlcmUgYXJlIHNlcGFy YXRlIHBvcnRzIGZvciBTU0ggKDIyKSBhbmQgbmV0Y29uZiBvdmVyIFNTSCAoODMwKSAtDQpkb2Vz IHRoaXMgbWVhbiB0aGlzIHByb3Bvc2FsIHdvdWxkIG5lZWQgYSByZXZlcnNlIHBvcnQgZm9yIGV2 ZXJ5DQpTU0gtYmFzZWQgc2VydmljZT8NCg0KTm8sIHRoaXMgc3VibWlzc2lvbiBvbmx5IGFza3Mg SUFOQSB0byBhc3NpZ24gYSBzaW5nbGUgcG9ydCwgdG8gYm9vdHN0cmFwIHRoZSBTU0ggcHJvdG9j b2wuICBPbmNlIHRoZSBTU0ggc2Vzc2lvbiBpcyB1cCwgdGhlIFNTSCBjbGllbnQgY2FuIG9wZW4g YW55IG51bWJlciBvZiBTU0ggY2hhbm5lbHMgZm9yIHR0eSwgc2Z0cCwgbmV0Y29uZiwgcG9ydC1m b3J3YXJkaW5nLCBldGMuDQoNClRoaXMgc29sdXRpb24gaXMgTk9UIGV4cGVjdGVkIHRvIHdvcmsg d2l0aCBhIHN0YW5kYXJkICdzc2gnIGNsaWVudC4gIFRoZSByZWFzb24gZm9yIHdoeSB0aGUgU1NI IHNlcnZlciBoYXMgYmVlbiBjb25maWd1cmUgdG8gY29ubmVjdCB0byB0aGUgU1NIIGNsaWVudCBp cyBkb21haW4gc3BlY2lmaWMuICBUaGUgZXhwZWN0YXRpb24gaXMgdGhhdCBhIGN1c3RvbSBhcHBs aWNhdGlvbiBpcyBkZXZlbG9wZWQgKHVzaW5nIHN0YW5kYXJkIFNTSCBjbGllbnQgbGlicmFyaWVz KSBmb3IgdGhlIHB1cnBvc2UuDQoNClRoYW5rcywNCktlbnQNCg== From touch@isi.edu Thu May 12 18:07:43 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B160113000B for ; Thu, 12 May 2011 18:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.121 X-Spam-Level: X-Spam-Status: No, score=-103.121 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0fir662AcPb for ; Thu, 12 May 2011 18:07:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id D7FD3130013 for ; Thu, 12 May 2011 18:07:41 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p4D17C6t014670 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 12 May 2011 18:07:12 -0700 (PDT) Message-ID: <4DCC8440.80109@isi.edu> Date: Thu, 12 May 2011 18:07:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 01:07:43 -0000 On 5/12/2011 6:01 PM, Kent Watsen wrote: > >> Any clue what port they're using for this? There doesn't appear to be >> one currently allocated. > > Juniper is using port 7104, I think, but there is no need to > maintain that compatibility since the message format presented in > this submission is not backward compatible with their's. For > instance, Juniper's existing format only supports one host-key, > whereas this this proposal supports all the host-keys the SSH server > has. Understood; I was asking because it sounded like Juniper was using a port they hadn't registered ;-( That should be fixed... >> Also, there are separate ports for SSH (22) and netconf over SSH >> (830) - does this mean this proposal would need a reverse port for >> every SSH-based service? > > No, this submission only asks IANA to assign a single port, to > bootstrap the SSH protocol. Once the SSH session is up, the SSH client > can open any number of SSH channels for tty, sftp, netconf, > port-forwarding, etc. Netconf over ssh uses a different port, as noted above. > This solution is NOT expected to work with a standard 'ssh' client. > The reason for why the SSH server has been configure to connect to the > SSH client is domain specific. The expectation is that a custom > application is developed (using standard SSH client libraries) for the > purpose. What's the reason for not solving this by having the client just listen on the SSH server port? Joe From kwatsen@juniper.net Thu May 12 19:53:19 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADBEE0593 for ; Thu, 12 May 2011 19:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doaTbzPzkgtt for ; Thu, 12 May 2011 19:53:19 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5994BE06FC for ; Thu, 12 May 2011 19:53:18 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTcydE00i1VWPqxT1Et5NAn96BmSRl2xW@postini.com; Thu, 12 May 2011 19:53:18 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 12 May 2011 19:49:56 -0700 From: Kent Watsen To: Joe Touch Date: Thu, 12 May 2011 19:49:53 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwRCim4y3Ua8se1RJOAkdje3gnNLQABzrWA Message-ID: <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> In-Reply-To: <4DCC8440.80109@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 02:53:19 -0000 PiBVbmRlcnN0b29kOyBJIHdhcyBhc2tpbmcgYmVjYXVzZSBpdCBzb3VuZGVkIGxpa2UgSnVuaXBl ciB3YXMgdXNpbmcgDQo+IGEgcG9ydCB0aGV5IGhhZG4ndCByZWdpc3RlcmVkIDstKCBUaGF0IHNo b3VsZCBiZSBmaXhlZC4uLg0KDQpJbmRlZWQsIGFuZCB0aGF0IGlzIGV4YWN0bHkgd2hhdCB3ZSdy ZSB0cnlpbmcgdG8gZG8gd2l0aCB0aGlzIHN1Ym1pc3Npb24uICBPdXIgcHJldmlvdXMgYXR0ZW1w dCB0byBoYXZlIElBTkEgYXNzaWduIGEgcG9ydCBmb3IgdGhpcyBlbmRlZCB3aXRoIHRoZWlyIHJl Y29tbWVuZGF0aW9uIHRvIGJyaW5nIGl0IHRvIElFVEYgZm9yIHN0YW5kYXJkaXphdGlvbi4gIEl0 J3MgdGFrZW4gYXdoaWxlLCBidXQgaGVyZSB3ZSBhcmUuDQoNCg0KDQo+IE5ldGNvbmYgb3ZlciBz c2ggdXNlcyBhIGRpZmZlcmVudCBwb3J0LCBhcyBub3RlZCBhYm92ZS4NCg0KVGhlIG5lZWQgZm9y IHRoZSBwb3J0IDgzMCBhc3NpZ25tZW50IHdhcyBvbmx5IHRvIGZhY2lsaXRhdGUgZmlsdGVyaW5n LiAgQXMgUkZDIDQ3NDIgc2F5czoNCg0KICAgSW4gb3JkZXIgdG8gYWxsb3cgTkVUQ09ORiB0cmFm ZmljIHRvIGJlIGVhc2lseSBpZGVudGlmaWVkIGFuZA0KICAgZmlsdGVyZWQgYnkgZmlyZXdhbGxz IGFuZCBvdGhlciBuZXR3b3JrIGRldmljZXMsIE5FVENPTkYgc2VydmVycyBNVVNUDQogICBkZWZh dWx0IHRvIHByb3ZpZGluZyBhY2Nlc3MgdG8gdGhlICJuZXRjb25mIiBTU0ggc3Vic3lzdGVtIG9u bHkgd2hlbg0KICAgdGhlIFNTSCBzZXNzaW9uIGlzIGVzdGFibGlzaGVkIHVzaW5nIHRoZSBJQU5B LWFzc2lnbmVkIFRDUCBwb3J0DQogICA8ODMwPi4gIFNlcnZlcnMgU0hPVUxEIGJlIGNvbmZpZ3Vy YWJsZSB0byBhbGxvdyBhY2Nlc3MgdG8gdGhlIG5ldGNvbmYNCiAgIFNTSCBzdWJzeXN0ZW0gb3Zl ciBvdGhlciBwb3J0cy4NCg0KSSBzdXBwb3NlIElFVEYgbWF5IGZlZWwgYSBzaW1pbGFyIG5lZWQg dG8gZmFjaWxpdGF0ZSBmaWx0ZXJpbmcgb24gYSBwZXIgU1NILWJhc2VkIHNlcnZpY2UsIGJ1dCBJ IHdvdWxkbid0IHJlY29tbWVuZCB0aGlzIGFzIHBvcnQtYmFzZWQgZmlsdGVyaW5nIGlzIG5vIGxv bmdlciBwcmFjdGljYWwgKGUuZy4gY29uc2lkZXIgdGhlIG51bWJlciBvZiBIVFRQLWJhc2VkIHBy b3RvY29scykuICBBcHBsaWNhdGlvbi1iYXNlZCBmaXJld2FsbHMgd2l0aCBkZWVwLWluc3BlY3Rp b24gY2FwYWJpbGl0eSBhcmUgbmVlZGVkIHRoZXNlIGRheXMuICBJbiBlaXRoZXIgY2FzZSwgdG8g dGhlIG9yaWdpbmFsIHF1ZXN0aW9uLCB0aGVyZSBpc27igJl0IGEgKm5lZWQqIGZvciBtb3JlIHRo YW4gb25lIElBTkEgYXNzaWduZWQgcG9ydCwgc2luY2UgU1NIIGFscmVhZHkgaGFzIGEgbWVjaGFu aXNtIGJ1aWx0IGludG8gaXQgZm9yIHRoZSBjbGllbnQgdG8gc2VsZWN0IHdoaWNoIHByb3RvY29s L3N1YnN5c3RlbSB0byBydW4gb24gYSBjaGFubmVsLg0KDQoNCg0KPiBXaGF0J3MgdGhlIHJlYXNv biBmb3Igbm90IHNvbHZpbmcgdGhpcyBieSBoYXZpbmcgdGhlIGNsaWVudCBqdXN0IGxpc3RlbiAN Cj4gb24gdGhlIFNTSCBzZXJ2ZXIgcG9ydD8NCg0KQmVjYXVzZSB0aGVuIGl0IHdvdWxkIGJlIGV4 cGVjdGVkIHRvIGJlIHRoZSBTU0ggc2VydmVyLiAgQXMgZGlzY3Vzc2VkIGluIHRoZSBJbnRyb2R1 Y3Rpb24sIGEgZ29hbCBvZiB0aGlzIGRyYWZ0IGlzIHRvIGVuc3VyZSB0aGUgZGV2aWNlIGlzIGFs d2F5cyB0aGUgU1NIIHNlcnZlciBhbmQgdGhlIGFwcGxpY2F0aW9uIGlzIGFsd2F5cyB0aGUgU1NI IGNsaWVudC4gIFdlIGRvbid0IHdhbnQgdG8gZGlzdHVyYiB3aGljaCBwZWVyIGlzIHdoaWNoIGFz IGZhciBhcyB0aGUgU1NIIFRyYW5zcG9ydCwgQXV0aGVudGljYXRpb24sIGFuZCBDb25uZWN0aW9u IHByb3RvY29scyBhcmUgY29uY2VybmVkLg0KDQoNClRoYW5rcywNCktlbnQNCg0KDQo= From j.schoenwaelder@jacobs-university.de Thu May 12 21:33:39 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A48E06B1 for ; Thu, 12 May 2011 21:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBNiQLaJsUEG for ; Thu, 12 May 2011 21:33:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 83BBEE068D for ; Thu, 12 May 2011 21:33:38 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EF1F20BFD; Fri, 13 May 2011 06:33:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mtw-QpJiLJ6V; Fri, 13 May 2011 06:33:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 968BD20BFC; Fri, 13 May 2011 06:33:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 930D11876F04; Fri, 13 May 2011 06:33:34 +0200 (CEST) Date: Fri, 13 May 2011 06:33:34 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110513043334.GA5184@elstar.local> Mail-Followup-To: Kent Watsen , Joe Touch , "ietf-ssh@NetBSD.org" , "saag@ietf.org" References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 04:33:39 -0000 On Thu, May 12, 2011 at 07:49:53PM -0700, Kent Watsen wrote: > The need for the port 830 assignment was only to facilitate filtering. As RFC 4742 says: > > In order to allow NETCONF traffic to be easily identified and > filtered by firewalls and other network devices, NETCONF servers MUST > default to providing access to the "netconf" SSH subsystem only when > the SSH session is established using the IANA-assigned TCP port > <830>. Servers SHOULD be configurable to allow access to the netconf > SSH subsystem over other ports. > > I suppose IETF may feel a similar need to facilitate filtering on a per SSH-based service, but I wouldn't recommend this as port-based filtering is no longer practical (e.g. consider the number of HTTP-based protocols). Application-based firewalls with deep-inspection capability are needed these days. In either case, to the original question, there isn’t a *need* for more than one IANA assigned port, since SSH already has a mechanism built into it for the client to select which protocol/subsystem to run on a channel. > The subsystem is selected through the encrypted channel, something difficult to filter on. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From touch@isi.edu Fri May 13 08:02:50 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30632E074F for ; Fri, 13 May 2011 08:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6sHFtZ5gHGh for ; Fri, 13 May 2011 08:02:49 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id B19D2E065A for ; Fri, 13 May 2011 08:02:49 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p4DF2DH4024676 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 13 May 2011 08:02:23 -0700 (PDT) Message-ID: <4DCD47F5.5000102@isi.edu> Date: Fri, 13 May 2011 08:02:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p4DF2DH4024676 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 15:02:50 -0000 On 5/12/2011 7:49 PM, Kent Watsen wrote: >> Understood; I was asking because it sounded like Juniper was using >> a port they hadn't registered ;-( That should be fixed... > > Indeed, and that is exactly what we're trying to do with this > submission. Our previous attempt to have IANA assign a port for this > ended with their recommendation to bring it to IETF for standardization. > It's taken awhile, but here we are. Sure. In the meantime, Juniper shouldn't be using an unassigned port number in a public distribution, though. ;-) >> Netconf over ssh uses a different port, as noted above. > > The need for the port 830 assignment was only to facilitate filtering. Yes. And will the need for a reverse port create a similar need for every such current SSH-based port assignment to have a corresponding reverse-channel port assignment? That would be undesirable... >> What's the reason for not solving this by having the client just listen >> on the SSH server port? > > Because then it would be expected to be the SSH server. Well, seems to me that if the server is initiating the connection, then it *is* a server (where I define server as "host that listens on a registered port"). The particular roles of who checks what certificate should be negotiated in-band, IMO. Joe From kwatsen@juniper.net Fri May 13 09:43:32 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E794E06E0 for ; Fri, 13 May 2011 09:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl+Gz-LWUWCY for ; Fri, 13 May 2011 09:43:31 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1986DE06BE for ; Fri, 13 May 2011 09:43:30 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTc1fpKcvWk+WM1uYQqStnZNwQd1QDjLF@postini.com; Fri, 13 May 2011 09:43:31 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 13 May 2011 09:42:02 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Fri, 13 May 2011 09:42:00 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwRJu7D/iwEip/+RsiWtQa8a6CrfgAXG3ZQ Message-ID: <84600D05C20FF943918238042D7670FD3E7E4A75AB@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <20110513043334.GA5184@elstar.local> In-Reply-To: <20110513043334.GA5184@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 16:43:32 -0000 DQo+IFRoZSBzdWJzeXN0ZW0gaXMgc2VsZWN0ZWQgdGhyb3VnaCB0aGUgZW5jcnlwdGVkIGNoYW5u ZWwsIHNvbWV0aGluZyBkaWZmaWN1bHQgdG8gZmlsdGVyIG9uLg0KDQpUcnVlLiAgVGhvdWdoIHNv bWUgZmlyZXdhbGxzIGNhbiBiZSBwcm92aWRlZCB0aGUgYmFja2VuZCBzZXJ2ZXIncyBwcml2YXRl IGtleShzKSBpbiBvcmRlciB0byBpbnNwZWN0IHRoZSB0cmFmZmljLiAgVGhpcyBmZWF0dXJlIGlz IG1vcmUgcHJldmFsZW50IG9uIGluZHVzdHJpYWwgZmlyZXdhbGxzIHRoYW4gY29uc3VtZXItZ3Jh ZGUgZmlyZXdhbGxzLg0KDQpPZiBjb3Vyc2UsIHRoZXJlIGlzIGEgY2F0Y2gtMjIgdG8gdGhpcyBp cyB0aGF0LCBhdCBsZWFzdCBpbiBvdXIgYXBwbGljYXRpb24gb2YgdGhpcyBwcm9wb3NhbCwgdGhl IGRldmljZSB0aGF0IHRoZSAiY2FsbGluZyBob21lIiBtYW55IHRpbWVzIChidXQgbm90IGFsd2F5 cyAtIHNlZSBkcmFmdCBmb3IgZGV0YWlscykgaXMgdGhlIGdhdGV3YXkgZGV2aWNlIGhhdmluZyB0 aGUgZmlyZXdhbGxpbmcgZnVuY3Rpb25hbGl0eS4NCg0KU3RpbGwsIEkgY29uY3VyIHdpdGggeW91 ciBwcmVtaXNlIHRoYXQgdGhlIHNvbHV0aW9uIHNob3VsZG4ndCBkaXNjYXJkIHRoZSBhYmlsaXR5 IHRvIGRvIHBvcnQtbGV2ZWwgZmlsdGVyaW5nIGZvciBlYWNoIFNTSC1iYXNlZCBwcm90b2NvbCB0 aGF0IGhhcyBiZWVuIHJldmVyc2VkLiAgVGhlIHF1ZXN0aW9uIHJlbWFpbnMsIHRob3VnaCwgaWYg dGhlcmUgc2hvdWxkIGJlIGEgbmV3IHBvcnQtYXNzaWdubWVudCBmb3IgZWFjaCBTU0gtYmFzZWQg cHJvdG9jb2wgb3IgaWYgdGhlIGV4aXN0aW5nIHBvcnRzIGFyZSByZXB1cnBvc2VkLg0KDQpXb3Vs ZCByZXB1cnBvc2luZyBleGlzdGluZyBwb3J0cyBiZSB0b28gYW1iaWd1b3VzLCBkdWUgdG8gdGhl bSBoYXZpbmcgZHVhbCByb2xlcz8NCg0KDQpQUzogUGVyIFRvbSdzIGNvbW1lbnQsIEkndmUgQkND LWVkIHRoZSAiaWV0Zi1zc2giIGxpc3QgdG8gYnJpbmcgdGhpcyBkaXNjdXNzaW9uIHRvIG9uZSBs aXN0LiAgSSdtIGNob29zaW5nIHRoZSBTQUFHIGxpc3QgcHJpbWFyaWx5IGJlY2F1c2UgaXQgaXMg YW4gb2ZmaWNpYWwgSUVURiBsaXN0LiAgSG9wZSB0aGlzIGlzIE9LIHdpdGggYWxsLg0KDQpUaGFu a3MsDQpLZW50DQoNCg0K From mouse@Sparkle.Rodents-Montreal.ORG Fri May 13 09:58:48 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA360E0825 for ; Fri, 13 May 2011 09:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmAU7oRFj62D for ; Fri, 13 May 2011 09:58:48 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id A442FE0823 for ; Fri, 13 May 2011 09:58:47 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA01162; Fri, 13 May 2011 12:58:45 -0400 (EDT) Date: Fri, 13 May 2011 12:58:45 -0400 (EDT) From: der Mouse Message-Id: <201105131658.MAA01162@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 13 May 2011 12:56:41 -0400 (EDT) To: saag@ietf.org, ietf-ssh@netbsd.org In-Reply-To: <84600D05C20FF943918238042D7670FD3E7E4A75AB@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <20110513043334.GA5184@elstar.local> <84600D05C20FF943918238042D7670FD3E7E4A75AB@EMBX01-HQ.jnpr.net> Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 16:58:48 -0000 > PS: Per Tom's comment, I've BCC-ed the "ietf-ssh" list to bring this > discussion to one list. I'm choosing the SAAG list primarily because > it is an official IETF list. Hope this is OK with all. For what it may be worth, I'd say the SSH list is better for discussing the technical aspects of the draft as it relates to SSH; the SAAG list (or maybe even some other IETF list; I hardly know them all) is perhaps better for discussing meta-issues such as what ports to use. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From lnovikov@mitre.org Fri May 13 10:02:15 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22D5E0824; Fri, 13 May 2011 10:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC95GiulB2Gm; Fri, 13 May 2011 10:02:15 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 03BFCE068E; Fri, 13 May 2011 10:02:14 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 543D121B1C6C; Fri, 13 May 2011 13:02:14 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4B92121B0216; Fri, 13 May 2011 13:02:14 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 13 May 2011 13:02:14 -0400 From: "Novikov, Lev" To: "saag@ietf.org" Date: Fri, 13 May 2011 13:01:05 -0400 Thread-Topic: BoF Request for CICM at IETF 81 Thread-Index: AcwRj1iyU3mEFP0FTbiX7uP3S3GSUQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "CICM Discussion List \(cicm@ietf.org\)" Subject: [saag] BoF Request for CICM at IETF 81 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 17:02:15 -0000 I'm formally requesting a BoF at IETF 81 to form a CICM WG based on the dra= ft charter below. Updated version at: http://code.google.com/p/ietf-cicm/wiki/WGCharter Discussion also at: cicm@ietf.org Thanks, Lev Draft CICM Working Group Charter =3D Description of Working Group =3D The Common Interface to Cryptographic Modules (CICM) API provides high=20 assurance crypto applications with a security framework that accommodates t= he=20 needs of a high assurance environment including security domain separation,= =20 and enhanced module, key, and channel management capabilities. The purpose of the CICM Working Group is to shepherd the CICM specification= =20 documents to publication and provide guidance for any new submissions relat= ed=20 to high assurance cryptos. Specifically, the Working Group will: * Complete existing requests: * replace algorithm strings with OIDs * use ABNF notation for unique identifiers syntax * add module events for symmetric and asymmetric key filled * Shepard the following documents to publication: * draft-lanz-cicm * draft-lanz-cicm-lm * draft-lanz-cicm-mm * draft-lanz-cicm-km * draft-lanz-cicm-cm =3D Goals and Milestones =3D TBD WGLC on draft-lanz-cicm-lm TBD WGLC on draft-lanz-cicm TBD WGLC on draft-lanz-cicm-mm TBD WGLC on draft-lanz-cicm-km TBD Submit draft-lanz-cicm to the IESG as Proposed Standard From kwatsen@juniper.net Fri May 13 10:07:24 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1DAE071C for ; Fri, 13 May 2011 10:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsWXwqymOVWn for ; Fri, 13 May 2011 10:07:23 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 36CFFE070C for ; Fri, 13 May 2011 10:07:22 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTc1k7k6THTK/ePKUiOpp9+raBerpHMD3@postini.com; Fri, 13 May 2011 10:07:23 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 13 May 2011 10:04:15 -0700 From: Kent Watsen To: der Mouse , "saag@ietf.org" , "ietf-ssh@netbsd.org" Date: Fri, 13 May 2011 10:04:13 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwRjwmhxRUHtWr4Q46puHQnnZBBfgAAEV9Q Message-ID: <84600D05C20FF943918238042D7670FD3E7E4A7612@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <20110513043334.GA5184@elstar.local> <84600D05C20FF943918238042D7670FD3E7E4A75AB@EMBX01-HQ.jnpr.net> <201105131658.MAA01162@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201105131658.MAA01162@Sparkle.Rodents-Montreal.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 17:07:24 -0000 OK, then let's flip it the other way - sorry about that Anyone responding to my last email, please put ietf-ssh back into the "To" = line and BCC saag Mea culpa! -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of der= Mouse Sent: Friday, May 13, 2011 12:59 PM To: saag@ietf.org; ietf-ssh@netbsd.org Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review > PS: Per Tom's comment, I've BCC-ed the "ietf-ssh" list to bring this > discussion to one list. I'm choosing the SAAG list primarily because > it is an official IETF list. Hope this is OK with all. For what it may be worth, I'd say the SSH list is better for discussing the technical aspects of the draft as it relates to SSH; the SAAG list (or maybe even some other IETF list; I hardly know them all) is perhaps better for discussing meta-issues such as what ports to use. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From paul.hoffman@vpnc.org Fri May 13 14:02:16 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FE5E077D for ; Fri, 13 May 2011 14:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiErMg4nxelZ for ; Fri, 13 May 2011 14:02:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 387F4E07D8 for ; Fri, 13 May 2011 14:02:15 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4DL2Dwk069534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 May 2011 14:02:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DCD47F5.5000102@isi.edu> Date: Fri, 13 May 2011 14:02:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <4DCD47F5.5000102@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 21:02:16 -0000 [[ I think both mailing lists should remain on the mail. The issues = relate to both. ]] On May 13, 2011, at 8:02 AM, Joe Touch wrote: >>> Netconf over ssh uses a different port, as noted above. >>=20 >> The need for the port 830 assignment was only to facilitate = filtering. >=20 > Yes. And will the need for a reverse port create a similar need for = every such current SSH-based port assignment to have a corresponding = reverse-channel port assignment? That would be undesirable... +1. A single reverse-port protocol that has a way to say "and I'm going = to be doing X protocol" would be a much better design. >>> What's the reason for not solving this by having the client just = listen >>> on the SSH server port? >>=20 >> Because then it would be expected to be the SSH server. >=20 > Well, seems to me that if the server is initiating the connection, = then it *is* a server (where I define server as "host that listens on a = registered port"). Fully agree. The design of this draft sounds like it can be summarized = as "an entity that is normally a client becomes a server for a short = period while it gets information from the entity that is normally a = server". At the point that the was-a-client becomes a short-term server, = why not make it a real SSH server? > The particular roles of who checks what certificate should be = negotiated in-band, IMO. That sounds right to me. --Paul Hoffman From ietfc@btconnect.com Fri May 13 01:18:27 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C4CE06FA for ; Fri, 13 May 2011 01:18:27 -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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByfXUfAUExaE for ; Fri, 13 May 2011 01:18:27 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id BF860E0675 for ; Fri, 13 May 2011 01:18:26 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2bthomr09.btconnect.com with SMTP id CWM22165; Fri, 13 May 2011 09:18:10 +0100 (BST) Message-ID: <012b01cc113d$b72da180$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Kent Watsen" , "Joe Touch" References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> Date: Fri, 13 May 2011 09:16:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4DCCE941.0072, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.5.13.73916:17:9.535, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, TO_IN_SUBJECT, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_1100_1199, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4DCCE942.021D,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false X-Mailman-Approved-At: Fri, 20 May 2011 08:21:10 -0700 Cc: ietf-ssh@NetBSD.org, saag@ietf.org Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 08:18:27 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Joe Touch" Cc: ; Sent: Friday, May 13, 2011 4:49 AM > > What's the reason for not solving this by having the client just listen > > on the SSH server port? > > Because then it would be expected to be the SSH server. As discussed in the Introduction, a goal of this draft is to ensure the device is always the SSH server and the application is always the SSH client. We don't want to disturb which peer is which as far as the SSH Transport, Authentication, and Connection protocols are concerned. > I do :-) SSH does not authenticate the user or the application, it authenticates SSH. The proper solution is channel binding in which case it does not matter who is SSH client and who is SSH server, and the existing SSH technology can be reused unaltered. Incidentally, I think that this discussion needs a home, be it ietf-ssh or whatever; having more than one makes a mess of mailing lists. Tom Petch > > Thanks, > Kent > > > From dfawcus@cisco.com Fri May 13 03:05:06 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C02E0761 for ; Fri, 13 May 2011 03:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BZCz6PaLgAD for ; Fri, 13 May 2011 03:05:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CCE2EE075C for ; Fri, 13 May 2011 03:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dfawcus@cisco.com; l=557; q=dns/txt; s=iport; t=1305281105; x=1306490705; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=WkzWMUGtDhJB0lDTzF/O1Fh/pVodLKeLfQPgNDe6C0A=; b=aLmmZlOoWyONoGeI/nualVMGE+d+fnZOObP4cWamSuKHMcUB/dPH5Qve j3CWoomnfyl7TOeBRNjMrayKLUDQDLseB+8ITUllwoiB2j1UWmW36jMFM pgiDlCzDvuKpdgHOZ1XquXfxWfRaERZ0HD4nBh5yp14h5G3tVxwiUIMCp c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkEAC4CzU2Q/khLgWdsb2JhbACmARQBARYmJahTniGGFQSeeQ X-IronPort-AV: E=Sophos;i="4.64,363,1301875200"; d="scan'208";a="88323872" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 May 2011 10:04:49 +0000 Received: from gpk-lds-007.cisco.com (gpk-lds-007.cisco.com [64.103.78.12]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4DA4nB7007668; Fri, 13 May 2011 10:04:49 GMT Received: from gpk-lds-007.cisco.com (localhost [127.0.0.1]) by gpk-lds-007.cisco.com (8.13.1/8.13.1) with ESMTP id p4DA4lgA031732; Fri, 13 May 2011 11:04:47 +0100 Received: (from dfawcus@localhost) by gpk-lds-007.cisco.com (8.13.1/8.13.1/Submit) id p4DA4k2k031682; Fri, 13 May 2011 11:04:46 +0100 Date: Fri, 13 May 2011 11:04:46 +0100 From: Derek Fawcus To: "t.petch" Message-ID: <20110513100446.GB11309@gpk-lds-007.cisco.com> References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <012b01cc113d$b72da180$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012b01cc113d$b72da180$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Fri, 20 May 2011 08:21:08 -0700 Cc: ietf-ssh@NetBSD.org, saag@ietf.org Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 10:05:06 -0000 On Fri, May 13, 2011 at 09:16:40AM +0200, t.petch wrote: > SSH does not authenticate the user or the application, it authenticates SSH. > > The proper solution is channel binding in which case it does not matter who > is SSH client and who is SSH server, and the existing SSH technology can > be reused unaltered. Quite. I recall looking at this a few years ago. The ssh protocols are largely symmetrical, as I recall it should be possible to flip roles once transport has completed, but before userauth or connection are started. .pdf From kwatsen@juniper.net Fri May 13 11:18:59 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC42E07EE for ; Fri, 13 May 2011 11:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOu-mE0OsHIS for ; Fri, 13 May 2011 11:18:59 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 8B254E07EC for ; Fri, 13 May 2011 11:18:58 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTc12BZ2URQsrd7ja+GKUfZToT6P0DFb4@postini.com; Fri, 13 May 2011 11:18:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 13 May 2011 11:17:52 -0700 From: Kent Watsen To: Derek Fawcus , t.petch Date: Fri, 13 May 2011 11:17:49 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwRVTyRWuh7ROWERNqZgHBi+PGf5AAMeFXw Message-ID: <84600D05C20FF943918238042D7670FD3E7E4A776F@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <012b01cc113d$b72da180$4001a8c0@gateway.2wire.net> <20110513100446.GB11309@gpk-lds-007.cisco.com> In-Reply-To: <20110513100446.GB11309@gpk-lds-007.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 20 May 2011 08:21:10 -0700 Cc: "ietf-ssh@NetBSD.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 18:18:59 -0000 > dfawcus@cisco.com writes:=20 > > The ssh protocols are largely symmetrical, as I recall it should be poss= ible > to flip roles once transport has completed, but before userauth or conne= ction > are started. If the application (using nomenclature from the draft) logs into the device= via userauth, then it follows that the device has to be the peer that pres= ents its host-key during the diffie-helman key exchange. Thus the role-fli= p has to occur either before the transport protocol begins, as proposed by = this draft, or at the very beginning of the transport protocol (i.e. tap in= to the reserved uint32 in the SSH_MSG_KEXINIT message). =20 Whether the roles are negotiated in-band or flipped prior to the start of t= he SSH protocol, the goal is for the device to always be the SSH server and= the application to always be the SSH client. PS: BCC-ing SAAG list, per der Mouse's suggestion Thanks, Kent From kwatsen@juniper.net Mon May 23 10:59:46 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5437BE0658 for ; Mon, 23 May 2011 10:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWZUNusbOBN8 for ; Mon, 23 May 2011 10:59:44 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 02F83E06F1 for ; Mon, 23 May 2011 10:59:43 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTdqgjFYQXD5axBW/anl/Z0AewoUg+9AA@postini.com; Mon, 23 May 2011 10:59:44 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 23 May 2011 10:56:59 -0700 From: Kent Watsen To: Paul Hoffman Date: Mon, 23 May 2011 10:56:52 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwRsRCvEVeAj7lsT4e6qoQ50HGnZgD9Apdg Message-ID: <84600D05C20FF943918238042D7670FD3E7EF93B55@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <4DCD47F5.5000102@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 17:59:46 -0000 > I think both mailing lists should remain on the mail. The issues=20 > relate to both. OK, we'll keep both on, just as the Security ADs originally suggested. > > Yes. And will the need for a reverse port create a similar need for=20 > > every such current SSH-based port assignment to have a corresponding=20 > > reverse-channel port assignment? That would be undesirable... > > +1. A single reverse-port protocol that has a way to say "and I'm going=20 > to be doing X protocol" would be a much better design. Sounds a little bit like the tcpmux protocol. Do you think how SSH opens channels/subsystems is not good enough? A proliferation of ports doesn't sound good, but others expressed a need for ports to support port-based firewall filters. How many ssh-based protocols are there currently? I=20 only know of two (SSH/SCP/SFTP:22 and NETCONF:830) - are there any others? = =20 > The design of this draft sounds like it can be summarized as "an entity > that is normally a client becomes a server for a short period while it > gets information from the entity that is normally a server". At the=20 > point that the was-a-client becomes a short-term server, why not make > it a real SSH server? What does this means at a protocol level? Does the application present a SSH host-key during DH key exchange and the device logs into the applicatio= n via userauth? - if so, then please realize that this is exactly what we're trying to prevent. We want the device to always be the peer that presents its SSH host key, whether due to the application connecting to its port 22 or because the device connected to the app's Reverse SSH port. Likewise, we always want the app to be the peer that userauth's to the device,=20 regardless how the transport was setup. > > The particular roles of who checks what certificate should be negotiate= d > > in-band, IMO. > > That sounds right to me. This would only be necessary if there are no new port assignments as,=20 otherwise, each peer *knows* which role to assume. For instance, each peer knows its role if started like this: app: ssh --listen --handler /usr/local/bin/myapp device: sshd --connect : --id 234230 --hmackey secret Otherwise, if there are no new port assignments (i.e. =3D=3D22), then we'd have to have in-band negotiation, perhaps by the device=20 sending a special identification string (RFC 4253, section 4.2) like this? SSH-2.0-OpenSSH_5.6 Reverse SSH If having in-band negotiation, then we should also extend the SSH=20 Protocol to support device identification and automatic authentication of host keys other than PGP and x.509 certificates, this is the=20 essence of the REVERSE-SSH-CONN-INFO message in the draft. Thanks, Kent From paul.hoffman@vpnc.org Mon May 23 11:41:47 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA603E07D6 for ; Mon, 23 May 2011 11:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IMJkk8uM5OE for ; Mon, 23 May 2011 11:41:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 75C42E07D3 for ; Mon, 23 May 2011 11:41:46 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4NIfi2L066805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 May 2011 11:41:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <84600D05C20FF943918238042D7670FD3E7EF93B55@EMBX01-HQ.jnpr.net> Date: Mon, 23 May 2011 11:41:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <4DCD47F5.5000102@isi.edu> <84600D05C20FF943918238042D7670FD3E7EF93B55@EMBX01-HQ.jnpr.net> To: Kent Watsen X-Mailer: Apple Mail (2.1084) Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 18:41:47 -0000 On May 23, 2011, at 10:56 AM, Kent Watsen wrote: >> I think both mailing lists should remain on the mail. The issues=20 >> relate to both. >=20 > OK, we'll keep both on, just as the Security ADs originally suggested. >=20 >=20 >=20 >>> Yes. And will the need for a reverse port create a similar need for=20= >>> every such current SSH-based port assignment to have a = corresponding=20 >>> reverse-channel port assignment? That would be undesirable... >>=20 >> +1. A single reverse-port protocol that has a way to say "and I'm = going=20 >> to be doing X protocol" would be a much better design. >=20 > Sounds a little bit like the tcpmux protocol. Do you think how SSH = opens > channels/subsystems is not good enough? A proliferation of ports = doesn't > sound good, but others expressed a need for ports to support = port-based > firewall filters. =20 Firewalls should adapt to good protocol design; protocol design should = not be weakened to work with firewalls. (And I say this as someone who = likes firewalls.) > How many ssh-based protocols are there currently? I=20 > only know of two (SSH/SCP/SFTP:22 and NETCONF:830) - are there any = others? =20 You say that as if we never expect to have any more, which seems like = poor planning. For example, many people run VNC and other such protocols = on other ports. The "ssh -L 15901:localhost:5901 example.com" usage is = quite common. Making it harder for protocols other than NETCONF to use = SSH doesn't seem like a good plan at this point. >> The design of this draft sounds like it can be summarized as "an = entity >> that is normally a client becomes a server for a short period while = it >> gets information from the entity that is normally a server". At the=20= >> point that the was-a-client becomes a short-term server, why not make >> it a real SSH server? >=20 > What does this means at a protocol level? Does the application = present a > SSH host-key during DH key exchange and the device logs into the = application > via userauth? - if so, then please realize that this is exactly what = we're > trying to prevent. =20 I do realize that; I am proposing that what you are trying to prevent is = in fact fine, and a lot more rational than a "I'm a kind-of-server for = just a moment" design. > We want the device to always be the peer that presents > its SSH host key, whether due to the application connecting to its = port 22 > or because the device connected to the app's Reverse SSH port. = Likewise, > we always want the app to be the peer that userauth's to the device,=20= > regardless how the transport was setup. Understood. The draft does a reasonable job of matching that design. >>> The particular roles of who checks what certificate should be = negotiated >>> in-band, IMO. >>=20 >> That sounds right to me. >=20 > This would only be necessary if there are no new port assignments as,=20= > otherwise, each peer *knows* which role to assume. For instance, each > peer knows its role if started like this: >=20 > app: ssh --listen --handler /usr/local/bin/myapp > device: sshd --connect : --id 234230 --hmackey = secret >=20 >=20 > Otherwise, if there are no new port assignments (i.e. = =3D=3D22), > then we'd have to have in-band negotiation, perhaps by the device=20 > sending a special identification string (RFC 4253, section 4.2) like > this? >=20 > SSH-2.0-OpenSSH_5.6 Reverse SSH This assumes that all SSH use is only on the currently-assigned ports. = That ignores the "-L" use case I gave above, as well as future protocols = that want to run over SSH. > If having in-band negotiation, then we should also extend the SSH=20 > Protocol to support device identification and automatic authentication > of host keys other than PGP and x.509 certificates, this is the=20 > essence of the REVERSE-SSH-CONN-INFO message in the draft. That is one design; another is "when I am acting like a server, I am = actually a server". That seems a lot cleaner. --Paul Hoffman From kwatsen@juniper.net Mon May 23 16:19:56 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4870E07A9 for ; Mon, 23 May 2011 16:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEj-WGclt4Vb for ; Mon, 23 May 2011 16:19:55 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8C341E06BF for ; Mon, 23 May 2011 16:19:55 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTdrrmK8l0Bvu1280PYwAHgCglCqs2iGX@postini.com; Mon, 23 May 2011 16:19:55 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 23 May 2011 16:17:20 -0700 From: Kent Watsen To: Paul Hoffman Date: Mon, 23 May 2011 16:17:08 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwZeRN4w5GXI+PHTxOBxP6WcHTHBgAFHB5w Message-ID: <84600D05C20FF943918238042D7670FD3E7EF9406E@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <4DCD47F5.5000102@isi.edu> <84600D05C20FF943918238042D7670FD3E7EF93B55@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 23:19:56 -0000 > Firewalls should adapt to good protocol design; protocol design should > not be weakened to work with firewalls. (And I say this as someone who > likes firewalls.) Agreed - let's focus on a good protocol design ;) >> How many ssh-based protocols are there currently? I only know >> of two (SSH/SCP/SFTP:22 and NETCONF:830) - are there any others? =20 > > You say that as if we never expect to have any more, which seems like=20 > poor planning. For example, many people run VNC and other such protocols > on other ports. The "ssh -L 15901:localhost:5901 example.com" usage is > quite common. Making it harder for protocols other than NETCONF to use > SSH doesn't seem like a good plan at this point. I didn't mean to imply that there wouldn't be more, only that there are so few now and that new SSH-based protocols can define a reverse-port for themselves, if it makes sense to them to do so. I use that port forwarding line with my virtual machines. It's a good example because VNC is used to "manage" devices similar to NetConf, so it's plausible that a device might be configured to init a reverse ssh connection to support VNC. In this case, the `ssh` connection goes to port 22, so reversing it means that the device would connect to the=20 application's rssh port and, once the SSH Connection Protocol (RFC 4254) is running, the application can send a SSH_MSG_CHANNEL_OPEN/direct-tcpip request to open a tunnel to the VNC server. >> What does this means at a protocol level? Does the application present = a >> SSH host-key during DH key exchange and the device logs into the applica= tion >> via userauth? - if so, then please realize that this is exactly what we= 're >> trying to prevent. =20 > > I do realize that; I am proposing that what you are trying to prevent is= =20 > in fact fine, and a lot more rational than a "I'm a kind-of-server for=20 > just a moment" design. Thanks, Paul. I appreciate your endorsement. At least, I think it is an endorsement... (I'm not entirely sure per your last comment below) >> We want the device to always be the peer that presents >> its SSH host key, whether due to the application connecting to its port = 22 >> or because the device connected to the app's Reverse SSH port. Likewis= e, >> we always want the app to be the peer that userauth's to the device,=20 >> regardless how the transport was setup. > > Understood. The draft does a reasonable job of matching that design. > >=20 >> This would only be necessary if there are no new port assignments as,=20 >> otherwise, each peer *knows* which role to assume. For instance, each >> peer knows its role if started like this: >>=20 >> app: ssh --listen --handler /usr/local/bin/myapp >> device: sshd --connect : --id 234230 --hmackey secret >> =20 >> Otherwise, if there are no new port assignments (i.e. =3D=3D2= 2), >> then we'd have to have in-band negotiation, perhaps by the device=20 >> sending a special identification string (RFC 4253, section 4.2) like >> this? >>=20 >> SSH-2.0-OpenSSH_5.6 Reverse SSH > >This assumes that all SSH use is only on the currently-assigned ports. Tha= t ignores the "-L" use >case I gave above, as well as future protocols that= want to run over SSH. FWIW, I personally don't like repurposing the currently-assigned ports=20 because it would be confusing to suddenly not be sure that port 22 was for a SSH Server and port 830 was for a NetConf server. I only offered how we might support in-band negotiation with the identification string because it seemed folks wanted to explore that option. =20 I like having a single well-known port (like tcpmux/port 1) that can be used for any SSH-based protocol, leaving it to the client to select which ones to start via opening channels/subsystems. For instance, an app can have simultaneous channels open for Syslog, SNMP, NetConf, VNC, HTTPS, and TTY. Which reminds me that I've always wanted an ability for a SSH Client to get a listing of all the subsystems available on the server,=20 similar to tcpmux's "HELP" command (another draft?) Another option, that I'm a bit shy to promote, is to have *no* assigned=20 ports. This is technically feasible since the devices MUST be configured to connect to the applications (i.e. address, port, id, credentials, etc.). The devices never connect out of the blue, thus no well-known port is=20 required. But this strategy would entail applications using unassigned ports, the very thing that Joe Touch flagged the day I submitted the draft. >> If having in-band negotiation, then we should also extend the SSH=20 >> Protocol to support device identification and automatic authentication >> of host keys other than PGP and x.509 certificates, this is the=20 >> essence of the REVERSE-SSH-CONN-INFO message in the draft. > > >That is one design; another is "when I am acting like a server, I am=20 >actually a server". That seems a lot cleaner. This is the comment I mentioned above is being unsure if it means you like the current draft or not. Is the "I am actually a server" statement satisfied by having an application listening on a Reverse SSH port, where the entire "protocol" is merely to bootstrap the SSH protocol? Thanks again, Kent From touch@isi.edu Tue May 24 07:51:18 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8601BE06ED for ; Tue, 24 May 2011 07:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.168 X-Spam-Level: X-Spam-Status: No, score=-104.168 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM24oKkf6jT3 for ; Tue, 24 May 2011 07:51:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 01840E06AF for ; Tue, 24 May 2011 07:51:17 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p4OEoWaf012638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 May 2011 07:50:41 -0700 (PDT) References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <4DCD47F5.5000102@isi.edu> <84600D05C20FF943918238042D7670FD3E7EF93B55@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7EF9406E@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E7EF9406E@EMBX01-HQ.jnpr.net> Mime-Version: 1.0 (iPad Mail 8J3) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8J3) From: Joe Touch Date: Tue, 24 May 2011 07:50:40 -0700 To: Kent Watsen X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ietf-ssh@NetBSD.org" , Paul Hoffman , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 14:51:18 -0000 On May 23, 2011, at 4:17 PM, Kent Watsen wrote: >=20 > I like having a single well-known port (like tcpmux/port 1) that can be > used for any SSH-based protocol, leaving it to the client to select which > ones to start via opening channels/subsystems. =20 Why isn't that the current ssh port? > For instance, an app can > have simultaneous channels open for Syslog, SNMP, NetConf, VNC, HTTPS, > and TTY. Which reminds me that I've always wanted an ability for a SSH > Client to get a listing of all the subsystems available on the server,=20 > similar to tcpmux's "HELP" command (another draft?) That is what the dns srv records might do, so you could ootentkially use 53 f= or that. But wouldn't that be a security concern? > Another option, that I'm a bit shy to promote, is to have *no* assigned=20= > ports. This is technically feasible since the devices MUST be configured > to connect to the applications (i.e. address, port, id, credentials, etc.)= . > The devices never connect out of the blue, thus no well-known port is=20 > required. But this strategy would entail applications using unassigned > ports, the very thing that Joe Touch flagged the day I submitted the draft= . Using only ports from the dynamic range is fine, but won't appease firewall d= esigners.=20 Using the entire port range, or and single port that is from the assignable r= ange that hasn't been assigned to you is a problem (and I was concerned with= the latter in your submission). >=20 >>> If having in-band negotiation, then we should also extend the SSH=20 >>> Protocol to support device identification and automatic authentication >>> of host keys other than PGP and x.509 certificates, this is the=20 >>> essence of the REVERSE-SSH-CONN-INFO message in the draft. >>=20 >>=20 >> That is one design; another is "when I am acting like a server, I am=20 >> actually a server". That seems a lot cleaner. >=20 > This is the comment I mentioned above is being unsure if it means you > like the current draft or not. Is the "I am actually a server" statement > satisfied by having an application listening on a Reverse SSH port, where > the entire "protocol" is merely to bootstrap the SSH protocol? I'm a server if I listen on the ssh port. On that port you should indicate o= r negotiate specifics of each side's behavior in-band IMO.=20 Joe= From mouse@Sparkle.Rodents-Montreal.ORG Tue May 24 08:54:59 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A262E0730 for ; Tue, 24 May 2011 08:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2Ayc6B7PO9j for ; Tue, 24 May 2011 08:54:58 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4343DE0671 for ; Tue, 24 May 2011 08:54:58 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA07708; Tue, 24 May 2011 11:54:36 -0400 (EDT) Date: Tue, 24 May 2011 11:54:36 -0400 (EDT) From: der Mouse Message-Id: <201105241554.LAA07708@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Tue, 24 May 2011 11:45:48 -0400 (EDT) To: ietf-ssh@NetBSD.org, saag@ietf.org In-Reply-To: References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <4DCD47F5.5000102@isi.edu> <84600D05C20FF943918238042D7670FD3E7EF93B55@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7EF9406E@EMBX01-HQ.jnpr.net> Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:54:59 -0000 > I'm a server if I listen on the ssh port. On that port you should > indicate or negotiate specifics of each side's behavior in-band IMO. This sounds like a reasonable point of view to me. If your reversed ssh runs kex with roles reversed (ie, connection initiator takes the server's role, presenting its host key and such), then a passive snooper can tell the difference, so you might as well trigger the role reversal with a pre-kex extension packet. If your reversd ssh runs kex normally (initiator takes the client's role) but reverses things after that, then you can do it with an extension packet immediately after kex (before, and/or instead of, what would normally be userauth). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From kwatsen@juniper.net Wed May 25 15:31:44 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A4FE0680 for ; Wed, 25 May 2011 15:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfHlREp4v3j1 for ; Wed, 25 May 2011 15:31:44 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id B875CE07F2 for ; Wed, 25 May 2011 15:31:43 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTd2C5MxlfiDYV/5hkSP3Urp0Dv3Wz3zK@postini.com; Wed, 25 May 2011 15:31:43 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 25 May 2011 15:27:13 -0700 From: Kent Watsen To: der Mouse , "ietf-ssh@NetBSD.org" , "saag@ietf.org" Date: Wed, 25 May 2011 15:27:11 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwaKvLYFTRU5MWESc6JmKGzTWPjewA92vBw Message-ID: <84600D05C20FF943918238042D7670FD3E7F4FFF27@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7E4A71B1@EMBX01-HQ.jnpr.net> <4DCC7D50.9080308@isi.edu> <4DCC8440.80109@isi.edu> <84600D05C20FF943918238042D7670FD3E7E4A72FD@EMBX01-HQ.jnpr.net> <4DCD47F5.5000102@isi.edu> <84600D05C20FF943918238042D7670FD3E7EF93B55@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7EF9406E@EMBX01-HQ.jnpr.net> <201105241554.LAA07708@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201105241554.LAA07708@Sparkle.Rodents-Montreal.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [saag] draft-kwatsen-reverse-ssh submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 22:31:44 -0000 >> I'm a server if I listen on the ssh port. On that port you should >> indicate or negotiate specifics of each side's behavior in-band IMO. > >This sounds like a reasonable point of view to me. > >If your reversed ssh runs kex with roles reversed (ie, connection >initiator takes the server's role, presenting its host key and such), >then a passive snooper can tell the difference, so you might as well >trigger the role reversal with a pre-kex extension packet. OK, I'll submit an updated draft for this approach Thanks, Kent From nico@cryptonector.com Fri May 27 10:37:27 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFCBE0813 for ; Fri, 27 May 2011 10:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC9fBarUVZif for ; Fri, 27 May 2011 10:37:26 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id A4BD5E080F for ; Fri, 27 May 2011 10:37:26 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 86C10678055 for ; Fri, 27 May 2011 10:37:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to: content-type; q=dns; s=cryptonector.com; b=X+J4aFZElX/iYU30/uw8h yWTieL+TDCcPWltqYyqXg3P4XYvK6yuYlUODyai/na5OGfaG4LS5u3c0GNzpzVzR y176v3y/oeUH6qUwGJogZQk+xMeal6BF5rYFahccl8MuK7jwVd+Prc+1T3R+Q2EX ObNDxzjnsQ0ndb/VMifUK4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=Y0bvXH7gi6T9fWC6mMwcveR u2cA=; b=oQAC60phAnPWubVi+aDYohEI2ACnqG5BjMwYKCJKqrSk7bgaM1ov3TB 3aHZD2+qDsw0z3E4LiCLFPQa45lz5dwQ62mwR8ZJXmx4qBtivLW/B+Gz9j+ioCrR Rd9tBC3thovx0mTkebYzlZOAOgrpRijf3H1YtLuSc1qwnlxirYvY= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 527AB678057 for ; Fri, 27 May 2011 10:37:19 -0700 (PDT) Received: by vxg33 with SMTP id 33so1895257vxg.31 for ; Fri, 27 May 2011 10:37:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.133 with SMTP id ia5mr3331566vdb.239.1306517838605; Fri, 27 May 2011 10:37:18 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 27 May 2011 10:37:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 May 2011 12:37:18 -0500 Message-ID: From: Nico Williams To: saag@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [saag] W3C Identity paper on GSS-REST X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:37:27 -0000 Slides for all presentations are here: http://www.w3.org/2011/identity-ws/agenda.html These presentations were meant to take 5 minutes each -- the slide decks are correspondingly short. SAAGers might want to read some, if not all of the presentations. Nico --