From saag-bounces@ietf.org Mon Aug 4 03:58:23 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CB128C141; Mon, 4 Aug 2008 03:58:23 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E9228C162 for ; Mon, 4 Aug 2008 03:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.529 X-Spam-Level: X-Spam-Status: No, score=-5.529 tagged_above=-999 required=5 tests=[AWL=1.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9qYdGVvKSzB for ; Mon, 4 Aug 2008 03:58:20 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3B61828C110 for ; Mon, 4 Aug 2008 03:58:20 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m74AwOmP000987 for ; Mon, 4 Aug 2008 13:58:45 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 13:58:04 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 13:57:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 13:57:50 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201474527@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF72 SAAG draft minutes Thread-Index: Acj2IO/jrGcPyL4rS5CDsEwd7jjL0w== From: To: X-OriginalArrivalTime: 04 Aug 2008 10:57:54.0834 (UTC) FILETIME=[F2866720:01C8F620] X-Nokia-AV: Clean Subject: [saag] IETF72 SAAG draft minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org I've uploaded draft minutes of the SAAG session in Dublin here: http://www.ietf.org/proceedings/08jul/minutes/saag.txt Please send any corrections/additions to me and Tim. Best regards, Pasi _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Aug 4 04:25:08 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBAD3A6A8B; Mon, 4 Aug 2008 04:25:07 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844443A6A8B for ; Mon, 4 Aug 2008 04:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5BHSIl813yv for ; Mon, 4 Aug 2008 04:25:05 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C6B883A686C for ; Mon, 4 Aug 2008 04:25:05 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m74BOGEi033267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 04:24:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4891bfbd.1bbc720a.19a9.0373@mx.google.com> References: <4891bfbd.1bbc720a.19a9.0373@mx.google.com> Date: Mon, 4 Aug 2008 04:24:12 -0700 To: "Gregory M. Lebovitz" , saag@ietf.org From: Paul Hoffman Subject: Re: [saag] Comments: SAAG SSL-VPN Preso X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 6:37 AM -0700 7/31/08, Gregory M. Lebovitz wrote: >2 - there are (at least) three types of TLS-VPN functional modes. >Paul listed 2, web-proxy-rewriter and full network access. The 3rd >is a per-application forwarding and protection. This type is >different from the other two in that one or more specific >application types (e.g. MAPI, CIFS, HTTP, etc.) can be made to be >forwarded off the client through the TLS tunnel, while no other >traffic would pass through the VPN. Per-application forwarding is a sub-type of full network access. That is, it requires a shim be pushed to the user for the application to be tunneled through. It is just a matter of the VPN policy whether everything to the corporate network goes through the tunnel, just some of the traffic bound for the corportation goes through the tunnel, or everything coming off of the remote computer goes through the tunnel. >3 - Paul referred to an issue of a "Silent gateway-in-the-middle >attack" that is a security consideration/weakness of the TLS-VPNs. >Users of these products (and they are many, the majority now) might >find this characterization contrary to their perspective. The >entities that operate TLS-VPNs use them precisely to be able to know >and control what is and isn't going in and out of their networks. >They see these HTTPS forward-proxy-like features as a wonderful >enforcement tool of their entity's security policy for maintaining >their networks and securing/control their data. Fully agree. I called it an "attack" because, from the normal IETF security perspective, it is one. From the customer's perspective, it is the only way to enforce policy. The latter trumps the former. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Aug 4 07:27:31 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6403228C2BE; Mon, 4 Aug 2008 07:27:31 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6D628C2BE for ; Mon, 4 Aug 2008 07:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx5+0BN8xEtL for ; Mon, 4 Aug 2008 07:27:29 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 52B4928C2BD for ; Mon, 4 Aug 2008 07:27:29 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id DF51A294001; Mon, 4 Aug 2008 17:27:56 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 91B1D294004; Mon, 4 Aug 2008 17:27:55 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m74ERsjI023038; Mon, 4 Aug 2008 17:27:55 +0300 (IDT) Message-ID: <489711E6.50401@checkpoint.com> Date: Mon, 04 Aug 2008 15:27:50 +0100 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Paul Hoffman References: <4891bfbd.1bbc720a.19a9.0373@mx.google.com> In-Reply-To: Cc: saag@ietf.org Subject: Re: [saag] Comments: SAAG SSL-VPN Preso X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org See below. Yaron Paul Hoffman wrote: > At 6:37 AM -0700 7/31/08, Gregory M. Lebovitz wrote: >> 2 - there are (at least) three types of TLS-VPN functional modes. >> Paul listed 2, web-proxy-rewriter and full network access. The 3rd is >> a per-application forwarding and protection. This type is different >> from the other two in that one or more specific application types >> (e.g. MAPI, CIFS, HTTP, etc.) can be made to be forwarded off the >> client through the TLS tunnel, while no other traffic would pass >> through the VPN. > > Per-application forwarding is a sub-type of full network access. That > is, it requires a shim be pushed to the user for the application to be > tunneled through. It is just a matter of the VPN policy whether > everything to the corporate network goes through the tunnel, just some > of the traffic bound for the corportation goes through the tunnel, or > everything coming off of the remote computer goes through the tunnel. > This is true in theory, but not in practice. Full network access VPNs are rather OS-intrusive (require the installation of network adaptors). Per-app forwarding often requires much less infrastructure and thus can be deployed as OS "hooks", with lower end-user privileges. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Aug 4 08:56:00 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9568E28C2F6; Mon, 4 Aug 2008 08:56:00 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F953A6CDB for ; Mon, 4 Aug 2008 08:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqJQ6x4oo9Qe for ; Mon, 4 Aug 2008 08:55:58 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 224A63A6CDA for ; Mon, 4 Aug 2008 08:55:58 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m74Ft31N065996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 08:55:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <489711E6.50401@checkpoint.com> References: <4891bfbd.1bbc720a.19a9.0373@mx.google.com> <489711E6.50401@checkpoint.com> Date: Mon, 4 Aug 2008 08:49:08 -0700 To: Yaron Sheffer From: Paul Hoffman Cc: saag@ietf.org Subject: Re: [saag] Comments: SAAG SSL-VPN Preso X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 3:27 PM +0100 8/4/08, Yaron Sheffer wrote: >Paul Hoffman wrote: > >>At 6:37 AM -0700 7/31/08, Gregory M. Lebovitz wrote: >>>2 - there are (at least) three types of TLS-VPN functional modes. >>>Paul listed 2, web-proxy-rewriter and full network access. The 3rd >>>is a per-application forwarding and protection. This type is >>>different from the other two in that one or more specific >>>application types (e.g. MAPI, CIFS, HTTP, etc.) can be made to be >>>forwarded off the client through the TLS tunnel, while no other >>>traffic would pass through the VPN. >> >>Per-application forwarding is a sub-type of full network access. >>That is, it requires a shim be pushed to the user for the >>application to be tunneled through. It is just a matter of the VPN >>policy whether everything to the corporate network goes through the >>tunnel, just some of the traffic bound for the corportation goes >>through the tunnel, or everything coming off of the remote computer >>goes through the tunnel. >> >This is true in theory, but not in practice. Full network access >VPNs are rather OS-intrusive (require the installation of network >adaptors). Per-app forwarding often requires much less >infrastructure and thus can be deployed as OS "hooks", with lower >end-user privileges. Probably true. I was talking about from a VPN administrator's or user's perspective, not from a developer's perspective. Going back to Gregory's first point, we will do better talking in their terms instead of our own because then what we say can be used by them in their day-to-day work. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Mon Aug 4 13:31:27 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704CF3A6A34; Mon, 4 Aug 2008 13:31:27 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E866A3A6A34 for ; Mon, 4 Aug 2008 13:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEc-Fhhgb4TR for ; Mon, 4 Aug 2008 13:31:26 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A1F823A68AB for ; Mon, 4 Aug 2008 13:31:25 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CB729294006; Mon, 4 Aug 2008 23:31:53 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D4C28294001; Mon, 4 Aug 2008 23:30:10 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m74KUAjN018478; Mon, 4 Aug 2008 23:30:10 +0300 (IDT) Message-Id: From: Yoav Nir To: Yaron Sheffer In-Reply-To: <489711E6.50401@checkpoint.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 4 Aug 2008 23:30:00 +0300 References: <4891bfbd.1bbc720a.19a9.0373@mx.google.com> <489711E6.50401@checkpoint.com> X-Mailer: Apple Mail (2.928.1) Cc: saag@ietf.org Subject: Re: [saag] Comments: SAAG SSL-VPN Preso X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1947267736==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org --===============1947267736== Content-Type: multipart/signed; boundary=Apple-Mail-29--943567403; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-29--943567403 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 4, 2008, at 5:27 PM, Yaron Sheffer wrote: >> >> Per-application forwarding is a sub-type of full network access. >> That is, it requires a shim be pushed to the user for the >> application to be tunneled through. It is just a matter of the VPN >> policy whether everything to the corporate network goes through the >> tunnel, just some of the traffic bound for the corportation goes >> through the tunnel, or everything coming off of the remote computer >> goes through the tunnel. >> > This is true in theory, but not in practice. Full network access > VPNs are rather OS-intrusive (require the installation of network > adaptors). Per-app forwarding often requires much less > infrastructure and thus can be deployed as OS "hooks", with lower > end-user privileges. That really says that we've found a way to run the per-application version without administrator privileges and without scary operating system pop-ups for the user. To me that sounds like a hole that everybody's waiting for Microsoft to patch. But then that's what I think about full network access as well. --Apple-Mail-29--943567403 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDgwNDIw MzAwMVowIwYJKoZIhvcNAQkEMRYEFAuq5Lh7aUz5LBZuYH/kj2ZdRly1MIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQCEobWtL/gg CAXWzEgqUAMQ+FrGd9uQyW82U7yT+JAMAN4U0YmeavaMGy+JM/0+NSM/OCQ5wEjqZQmTSYVxjsxm SCyhmrgdwLX6XZKLi/Av//VDOsS2S3MBGJYRK8Nn/fdpVqfuzTGwUTDgwSVBWfPF4cZk437Rc8ID NtnAppLH9YwiHZ4b5JOdyq+Rz5HEYH4CULDfjemTAR86X4PnZNaX8KkcOb5EecK0KiDmrDi6sqy2 4XVE83rkz3RU1cnuwakLx9dE+moCMGim56NZSirwIiQ3vQueci3KP5ALfM9S6VIV2qan8D4lrEvp NkQDHXGBfW3G3disfJv55g2jfnmZAAAAAAAA --Apple-Mail-29--943567403-- --===============1947267736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============1947267736==-- From saag-bounces@ietf.org Tue Aug 5 03:06:11 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9003A6A8B; Tue, 5 Aug 2008 03:06:11 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9AD3A684E; Tue, 5 Aug 2008 03:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=0.984, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rdz-tr+u0Hi1; Tue, 5 Aug 2008 03:06:09 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C94DF3A67EC; Tue, 5 Aug 2008 03:06:08 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m75A6SWY014385; Tue, 5 Aug 2008 13:06:36 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 13:06:28 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 13:06:27 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 13:06:37 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201474CA2@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pasi's AD notes for July 2008 Thread-Index: Acj24vK/dBxTZcOPTeSrPyUU879LkQ== From: To: , X-OriginalArrivalTime: 05 Aug 2008 10:06:27.0034 (UTC) FILETIME=[EC7743A0:01C8F6E2] X-Nokia-AV: Clean Subject: [saag] Pasi's AD notes for July 2008 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org Hi all, Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - IPsec maintenance and extensions (ipsecme) WG was chartered in 2008-07-03 telechat. - SAAG mailing list has been moved from mit.edu to ietf.org. I'm hoping Sam Weiler can soon move the SecDir list, too. WORKING GROUPS DKIM - Waiting for WG to send list of RFC errata IDs the WG agrees on. EMU - draft-ietf-emu-gpsk: in AD Evaluation -- waiting for the WG to decide MAC length/key size issue before going to IETF last call. - ITU-T SG 17 has sent a liaison statement about their document X.1034, "Guidelines on EAP-based authentication and key management in a data communication network"; there was a short presentation in SAAG, too. The document itself is not yet available -- waiting for Tim/Zachary Zeltsan to send the document to the WG and the IETF liaison statement page. IPSECME - Discussing detailed document scopes with WG chairs; waiting for reply from them. - (not wearing AD hat) I promised to send my "things that need to be looked at" list about IKEv2bis to mailing list - (not wearing AD hat) Waiting for WG chairs to decide document authors/editors for the IPv6 draft. ISMS - I need to re-read the latest drafts and participate in naming-related discussion. KEYPROV - I promised to send comments about PSKC and DSKPP, including things I commented at the meeting. SASL - Waiting for charter update text from the chairs (>4 months) SYSLOG - draft-ietf-syslog-sign: I sent my AD evaluation comments to the list recently; waiting for WG to decide what to do. - draft-ietf-syslog-transport-tls: in IETF Last Call; on agenda of 2008-08-14 IESG telechat. - Talked with Joe about early port number assignment for syslog- transport-tls; if it's approved on 2008-08-14, assignment will happen within a week anyway, so early allocation wouldn't save much time. - draft-ietf-syslog-tc-mib: in RFC editor queue TLS - draft-ietf-tls-rfc4346-bis: still in AUTH48 -- waiting for Eric to provide reasons for changing pre-master secret handling. - draft-ietf-tls-ecc-new-mac: in IANA processing -- waiting (>1 month) for Eric to confirm that the IANA actions are OK - draft-ietf-tls-rsa-aes-gcm: in RFC editor queue, waiting for TLS 1.2 to come out. OTHER DOCUMENTS - draft-ietf-avt-rtcpssm: Talked with Joerg, Colin, and Cullen in Dublin about possible mitigations for misdirected feedback. Joerg will explore "feedback debug" messages that would tell which media stream the feedback is about; if this turns out to be too complex, or something that nobody would implement anyway, will consider just documenting the problems. - draft-santesson-digestbind: Talked with Stefan; I promised to read and send comments, and recommended independent submission to the RFC Editor. - draft-ietf-capwap-*: I sent a bunch of IETF last call comments; working on handling them. - PKCS #1/RFC 3447 update: There has been discussion about updating RFC 3447 to include the errata (from both RFC Editor and RSA Labs errata lists); James Randall from RSA promised to look at this. - draft-ietf-dime-mip6-split/draft-ietf-mip6-radius: I talked with Jari, Jouni, and Avi in Dublin about IKEv2 PSK and certificate modes. Various ways to handle them, but RADIUS packet size could be a problem. However, it seems there's no current need for those modes, could be solved later. - draft-mattsson-srtp-store-and-forward: I talked briefly with Rolf and Magnus in Dublin; I promised to read this and send comments. - draft-ietf-mpls-mpls-and-gmpls-security-framework: I have promised to read this, talk with Tim and others, and send comments. - "Security roadmap for routing protocols": talked with with Gregory, Danny, David, Ross and Tim in Dublin; I promised to read and send comments once Gregory sends something. - draft-ietf-netconf-tls: I have promised to read this and talk with Tim. DISCUSSES (active -- something happened within last month) - draft-hautakorpi-sipping-uri-list-handling-refused: text agreed, waiting for authors to submited a revised ID [since 2008-07-03] - draft-ietf-enum-experiences: talked briefly with Jon Peterson in Dublin -- waiting to hear more from the authors and/or Jon [since 2008-07-31] - draft-ietf-ipcdn-pktc-eventmess: text agreed, waiting for authors to submited a revised ID [since 2008-07-18] - draft-ietf-pwe3-pw-atm-mib: waiting for authors to reply to my comments or submit a revised ID [since 2008-07-02] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-ietf-bfd-base: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-multihop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-v4v6-1hop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-pce-pcep: some discussions about require changes has occured; waiting for proposed text or revised ID [since 2008-06-16] - draft-ietf-shim6-proto: waiting for Erik to propose something to solve IPsec interaction issue [since 2008-06-18] - draft-ietf-simple-imdn: waiting for authors to reply to my comments or submit a revised ID [since 2008-05-14] - draft-ietf-sipping-sbc-funcs: new version (-06) addressed all comments except one; text agreed for the remaining one, waiting for RFC editor note or revised ID [since 2008-06-17] - draft-ietf-tsvwg-emergency-rsvp: this document has large number of discusses/abstains; waiting for Magnus to figure out next steps [since 2008-06-03] - draft-ietf-v6ops-addcon: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-16] - draft-iijima-netconf-soap-implementation: version -09 addressed all my comments except one; waiting for authors to reply to the remaining one or submit a revised ID [since 2008-06-12] - draft-mraihi-inch-thraud: version -06 addressed some of my comments, but not all (and introduced some new issues); waiting for authors to reply to my comments or submit a revised ID [since 2008-06-19] --end-- _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Aug 5 05:45:00 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D50A3A6883; Tue, 5 Aug 2008 05:45:00 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40D93A684A for ; Tue, 5 Aug 2008 05:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_BAYES_5x8=0.8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRJPcfjDipeU for ; Tue, 5 Aug 2008 05:44:57 -0700 (PDT) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by core3.amsl.com (Postfix) with ESMTP id D23893A6883 for ; Tue, 5 Aug 2008 05:44:47 -0700 (PDT) Received: from mail.bright-prospects.com (ool-457430d8.dyn.optonline.net [69.116.48.216]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K54003K6OQID410@mta1.srv.hcvlny.cv.net> for saag@ietf.org; Tue, 05 Aug 2008 08:44:44 -0400 (EDT) Received: from IBMRBASCH ([192.168.15.187]) by mail.bright-prospects.com (8.13.1/8.13.1) with ESMTP id m75CiZ8N024975; Tue, 05 Aug 2008 08:44:41 -0400 Date: Tue, 05 Aug 2008 08:44:29 -0400 From: Richard Basch In-reply-to: To: 'Paul Hoffman' , saag@ietf.org Message-id: <008901c8f6f9$01b8ff90$0202fea9@IBMRBASCH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acj2JXi+Vc1JvMRkR4WlTrusI6acNwA0YfDA References: <4891bfbd.1bbc720a.19a9.0373@mx.google.com> Subject: Re: [saag] Comments: SAAG SSL-VPN Preso X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 7:24 AM 08/04/2008, Paul Hoffman wrote: >At 6:37 AM -0700 7/31/08, Gregory M. Lebovitz wrote: >>3 - Paul referred to an issue of a "Silent gateway-in-the-middle >>attack" that is a security consideration/weakness of the TLS-VPNs. >>Users of these products (and they are many, the majority now) might >>find this characterization contrary to their perspective. The >>entities that operate TLS-VPNs use them precisely to be able to know >>and control what is and isn't going in and out of their networks. >>They see these HTTPS forward-proxy-like features as a wonderful >>enforcement tool of their entity's security policy for maintaining >>their networks and securing/control their data. > Fully agree. I called it an "attack" because, from the normal IETF > security perspective, it is one. From the customer's perspective, it > is the only way to enforce policy. The latter trumps the former. I guess my view of whether it constitutes an "attack" depends on the ownership & control rights of the assets in question. If it is a corporate resource, a corporate operator of a TLS-VPN may be imposing security policies in-line, and while a user (employee) of a corporate resource may not appreciate such, it is hard to argue that such policy enforcement constitutes an attack on the resource. Of course, a user who may be using a personal resource may have a legitimate complaint about external entities imposing security policies on their personal resource, if there was no other agreement (i.e. employment contract stipulating that the user will comply with corporate security policies, etc.) I am not a lawyer, but it seems to me that an attack between two parties engaged in a collaborative partnership can only be measured by property rights (whether it be intellectual or tangible property rights). In the first example where an employee is using a corporate resource, it could be construed as an attack on the legal entity, known as a corporation, to have the user be able to violate the corporate entity's policies and rights. Perhaps I misinterpreted the form of attack to which Paul alluded. Sincerely, Richard Basch _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Aug 5 06:33:51 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6343A691C; Tue, 5 Aug 2008 06:33:51 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E002C3A67CC for ; Tue, 5 Aug 2008 06:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shZO7KAJoF-Z for ; Tue, 5 Aug 2008 06:33:49 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 17EE63A691C for ; Tue, 5 Aug 2008 06:33:49 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m75DX0Gd060001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2008 06:33:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <008901c8f6f9$01b8ff90$0202fea9@IBMRBASCH> References: <4891bfbd.1bbc720a.19a9.0373@mx.google.com> <008901c8f6f9$01b8ff90$0202fea9@IBMRBASCH> Date: Tue, 5 Aug 2008 06:27:54 -0700 To: Richard Basch , saag@ietf.org From: Paul Hoffman Subject: Re: [saag] Comments: SAAG SSL-VPN Preso X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org At 8:44 AM -0400 8/5/08, Richard Basch wrote: >Perhaps I misinterpreted the form of attack to which Paul alluded. The "attack" is that neither the remote access user nor the HTTPS server inside the corporate network agreed to having the tunnel be terminated and restarted. Both can see that it is happening (well, the user can see it if he's careful), but neither agreed to it. SSL VPNs explicitly try to make the remote access user "feel" like they are connecting to the internal resources, and they explicitly try to make the internal resource act as if there is a local user connecting to them. It is a nudge-nudge-wink-wink two-way spoofing that is visible. Fortunately, it doesn't matter. As you say, the corporation gets to make the security policy. In this case, there are two linked policies: "some SSL tunnels that were meant for an internal resource stop at the SSL VPN gateway instead of at the resource" and "the SSL VPN gateway can emulate a remote access user to internal HTTPS resources". --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Wed Aug 6 23:57:07 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199B53A6A31; Wed, 6 Aug 2008 23:57:07 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4783A6980; Wed, 6 Aug 2008 23:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0WzjUFiCDEM; Wed, 6 Aug 2008 23:57:04 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 2B3593A67A3; Wed, 6 Aug 2008 23:57:03 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m776vBf8000453; Thu, 7 Aug 2008 09:57:24 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 09:57:10 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 09:57:09 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 09:57:09 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C5BED@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Liaison Statement on ITU-T Recommendation X.1034 Thread-Index: Acj4Ws/4JKpPiu8HSZSfsI28ekt7fQ== From: To: X-OriginalArrivalTime: 07 Aug 2008 06:57:09.0756 (UTC) FILETIME=[CFD3ABC0:01C8F85A] X-Nokia-AV: Clean Cc: saag@ietf.org Subject: [saag] Liaison Statement on ITU-T Recommendation X.1034 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org The liaison statement from ITU-T SG 17 on X.1034 ("Guideline on extensible authentication protocol based authentication and key management in a data communication network"), which was briefly discussed in SAAG and EMU meetings, is now available here: https://datatracker.ietf.org/liaison/466/ Joe and Alan: if the EMU WG members have comments about the specification, a liaison statement reply from EMU WG to ITU-T SG 17 would probably be a good idea; please coordinate making such reply. Best regards, Pasi _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From saag-bounces@ietf.org Tue Aug 19 10:52:41 2008 Return-Path: X-Original-To: saag-archive@ietf.org Delivered-To: ietfarch-saag-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2282C3A69EA; Tue, 19 Aug 2008 10:52:41 -0700 (PDT) X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D1C3A69EA for ; Tue, 19 Aug 2008 10:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJuNgid2KTsf for ; Tue, 19 Aug 2008 10:52:35 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 0B3F13A68C3 for ; Tue, 19 Aug 2008 10:52:35 -0700 (PDT) Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 68F7340048 for ; Tue, 19 Aug 2008 11:49:04 -0600 (MDT) Message-ID: <48AB0845.8040109@stpeter.im> Date: Tue, 19 Aug 2008 11:52:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.16) Gecko/20080707 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: saag@ietf.org Subject: [saag] Jabber/XMPP end-to-end security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2068988883==" Sender: saag-bounces@ietf.org Errors-To: saag-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2068988883== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020504000706000306060504" This is a cryptographically signed message in MIME format. --------------ms020504000706000306060504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI, the XMPP developer community is currently discussing requirements for the end-to-end encryption of Jabber/XMPP traffic. Given that Jabber is used in a semi-official fashion by the IETF (and that the core XMPP RFCs, currently being revised via bis drafts, have previously been deemed to require end-to-end encryption), I figure that folks here might have an interest in the topic. The discussion starts here: http://mail.jabber.org/pipermail/security/2008-August/000067.html You can join the security@xmpp.org list via either of the following URLs: mailto:security-subscribe@xmpp.org http://mail.jabber.org/mailman/listinfo/security Some of the terminology might be unfamiliar. I'll work to create a glossary of sorts soon. Thanks. Peter --------------ms020504000706000306060504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA4MTkxNzUyMDVaMCMGCSqG SIb3DQEJBDEWBBS96ervMJ7VMYpn4pB3hZWP8xDMqTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQAYong6BO5bgEjBFYHIImvwhVTyzf4ofwfqW0XZ82jgNxbrjJUEbnfwBohvjfzkYQq+9XhC MYRlOn3255jSd8yeXQh2Zrv8mQwgtzqBE04kO8czmLStJ6dlnW0bIamgkCSbY38GRUHgSwnB KfZr+SxeaNexe92MH2v0cr5BS3Uyz55+o22ZTY7Wu3PydyskZTUpushzPIEls9QYe0FjAC0F myP+cUC0rVM9Wavpk6mn+InSaEo/sZoKRBtMyTC9Cc8EtnvLXFzGf6JIBim1c8QWz+OcJzT3 0K8qn2c/sCuQRC7XXuaAVrh3NnHLjBkYkY323QlDNM+7ZajmHFF744VGAAAAAAAA --------------ms020504000706000306060504-- --===============2068988883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --===============2068988883==--