From owner-rap@ops.ietf.org Mon Jul 28 23:30:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28736 for ; Mon, 28 Jul 2003 23:30:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hLBT-000Pco-7Q for rap-data@psg.com; Tue, 29 Jul 2003 03:29:55 +0000 Received: from [130.130.68.16] (helo=ziz.its.uow.edu.au) by psg.com with esmtp (Exim 4.20) id 19hLBQ-000Pcc-Hk for rap@ops.ietf.org; Tue, 29 Jul 2003 03:29:52 +0000 Received: from ziz (localhost [127.0.0.1]) by ziz.its.uow.edu.au (8.12.9/8.12.9) with ESMTP id h6T3TpGU009569 for ; Tue, 29 Jul 2003 13:29:51 +1000 (EST) Received: from inti.its.uow.edu.au ([130.130.37.4]) by ziz.its.uow.edu.au (MailMonitor for SMTP v1.2.2 ) ; Tue, 29 Jul 2003 13:29:50 +1000 (EST) Received: (from sendmail@localhost) by inti.its.uow.edu.au (8.12.9/8.12.9) id h6T3Topq004118 for ; Tue, 29 Jul 2003 13:29:50 +1000 (EST) Received: from mirapoint.uow.edu.au (mirapoint.uow.edu.au[130.130.68.27]) by inti.its.uow.edu.au (UWSMTPD 1.4) with ESMTP id 2484775.4053; Tuesday, 29 July 2003 13:29:43 +1000 Received: from mirapoint.uow.edu.au (localhost.uow.edu.au [127.0.0.1]) by mirapoint.uow.edu.au (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABJ37620; Tue, 29 Jul 2003 13:29:41 +1000 (EST) Received: from 144.132.138.227 by mirapoint.uow.edu.au (Mirapoint Messaging Server MOS 3.3.3-GR) with HTTP/1.1; Tue, 29 Jul 2003 13:29:41 +1000 Date: Tue, 29 Jul 2003 13:29:41 +1000 From: geg01@uow.edu.au Subject: COPS-TLS extensions To: rap@ops.ietf.org X-Mailer: Webmail Mirapoint Direct 3.3.3-GR MIME-Version: 1.0 Message-Id: <480e44fa.aacf76bd.8166900@mirapoint.uow.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=BAYES_30,FROM_ENDS_IN_NUMS,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Im am a student studying the use of COPS-PR for distributing firewall security policies over insecure networks. I thus far have a working Java implementation of COPS-PR and COPS- TLS however some issues have come to my attention regarding TLS session re-use/caching policies for COPS-TLS, as well as policies governing re-handshaking to renew keying material at an appropriate interval. From my understanding, it is the responsibility of the application that implements TLS to handle these issues, so for my work I am proposing some minor extensions to COPS-TLS that allow greater control over the underlying TLS. Just wandering if anyone has addressed these issues in the past, or if it is a pointless idea. Many thanks From owner-rap@ops.ietf.org Tue Jul 29 12:18:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28012 for ; Tue, 29 Jul 2003 12:18:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hX9b-00069D-Mo for rap-data@psg.com; Tue, 29 Jul 2003 16:16:47 +0000 Received: from [134.134.136.7] (helo=caduceus.jf.intel.com) by psg.com with esmtp (Exim 4.20) id 19hX9R-00067r-Nv for rap@ops.ietf.org; Tue, 29 Jul 2003 16:16:37 +0000 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h6TGAdw03118 for ; Tue, 29 Jul 2003 16:10:41 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h6TGBdk19257 for ; Tue, 29 Jul 2003 16:11:39 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003072909163325485 ; Tue, 29 Jul 2003 09:16:33 -0700 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 09:16:33 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: COPS-TLS extensions Date: Tue, 29 Jul 2003 09:16:33 -0700 Message-ID: Thread-Topic: COPS-TLS extensions Thread-Index: AcNVgewYCiywLyRDSlWwYTe4Yr56UQAZwhBA From: "Kulkarni, Amol" To: , X-OriginalArrivalTime: 29 Jul 2003 16:16:33.0876 (UTC) FILETIME=[C72CF140:01C355EC] X-Spam-Status: No, hits=-1.0 required=5.0 tests=BAYES_30,MAILTO_TO_SPAM_ADDR version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, You are correct in your observation that these are the responsibilities of the application that implements TLS. What are the extensions you are proposing? Please post them to this list. Thanks, Amol -----Original Message----- From: geg01@uow.edu.au [mailto:geg01@uow.edu.au]=20 Sent: Monday, July 28, 2003 8:30 PM To: rap@ops.ietf.org Subject: COPS-TLS extensions Hello Im am a student studying the use of COPS-PR for distributing=20 firewall security policies over insecure networks. I thus=20 far have a working Java implementation of COPS-PR and COPS- TLS however some issues have come to my attention regarding=20 TLS session re-use/caching policies for COPS-TLS, as well as=20 policies governing re-handshaking to renew keying material=20 at an appropriate interval. From my understanding, it is the responsibility of the=20 application that implements TLS to handle these issues, so=20 for my work I am proposing some minor extensions to COPS-TLS=20 that allow greater control over the underlying TLS. Just=20 wandering if anyone has addressed these issues in the past,=20 or if it is a pointless idea. Many thanks From owner-rap@ops.ietf.org Wed Jul 30 19:16:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22943 for ; Wed, 30 Jul 2003 19:16:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19i0A9-000AML-6W for rap-data@psg.com; Wed, 30 Jul 2003 23:15:17 +0000 Received: from [134.134.136.6] (helo=hermes.jf.intel.com) by psg.com with esmtp (Exim 4.20) id 19i0A6-000ALq-FA for rap@ops.ietf.org; Wed, 30 Jul 2003 23:15:14 +0000 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h6UND7v25677 for ; Wed, 30 Jul 2003 23:13:07 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h6UMd4Y06793 for ; Wed, 30 Jul 2003 22:39:04 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003073016151326373 ; Wed, 30 Jul 2003 16:15:13 -0700 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jul 2003 16:15:13 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: FW: COPS-TLS extensions Date: Wed, 30 Jul 2003 16:15:12 -0700 Message-ID: Thread-Topic: COPS-TLS extensions Thread-Index: AcNWSCSVK2341kW/TsmBYkXNG4KoygAqCOBA From: "Kulkarni, Amol" To: Cc: X-OriginalArrivalTime: 30 Jul 2003 23:15:13.0466 (UTC) FILETIME=[6E07F1A0:01C356F0] X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_20,MAILTO_TO_SPAM_ADDR version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Forwarding to the list for comments. Amol -----Original Message----- From: geg01@uow.edu.au [mailto:geg01@uow.edu.au]=20 Sent: Tuesday, July 29, 2003 8:10 PM To: Kulkarni, Amol Cc: geg01@uow.edu.au Subject: RE: COPS-TLS extensions Hello The first extension is a "Session Re-Negotiation Timer=20 Object". It consists of a 2 byte field indicating the=20 duration after which a TLS session must be renegotiated=20 between PEP and PDP. It also consists of a single byte flag=20 that indicates if session re-use is permitted. The object=20 would be appended to a Client-Accept message sent from the=20 TLS enabled PDP. The second is a "Session Re-Negotiation Required" message.=20 This will be a new COPS message ( arbitrary opcode ) that=20 contains a Session Re-Negotiation Timer Object. It will be=20 issued by the PDP when TLS re-keying must be performed=20 within the bounds of the time limit set in the initial=20 Session Re-Negotiation object in the Client-Accept. It would=20 be issued in the case that keying material is/may be=20 compromised, and immediate rekeying is required.=20 The final ( largely experimental ) extension is=20 a "Enable/Disable Cipher Mode" message. It will consist of a=20 new object that consists of 2 byte fields. The first field=20 identifies a COPS message op-code, the second is a flag with=20 values 0/1. The idea of the message is that it will be=20 issued by either a PEP or PDP prior to sending, for example,=20 a Report-State message that contains significant amounts of=20 data ( 10's of MBs e.g. a large firewall log ). When the=20 flag is set to 1, all subsequent COPS message that match the=20 designated opcode will not be encrypted ( i.e a TLS=20 handshake will be performed to disable encryption ). When it=20 is set to 0, only the next COPS message that matches the=20 opcode will not be encrypted. The idea will be to reduce=20 processing requirements on low powered devices or heavy=20 burdened PDPs when sending or receiving large amounts of=20 data. e.g for a small mobile PEP device that uses COPS-PR to=20 obtain its firewall policies, it may be necessary to have=20 policy decisions encrypted but large report state messages=20 can be left in plain text form.