Subject: COPS-TLS extensions

From: [email-masked]
Date: Tue, 29 Jul 2003 13:29:41 +1000

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: "Kulkarni, Amol" <[email-masked]>
Date: Tue, 29 Jul 2003 09:16:33 -0700

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: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 28, 2003 8:30 PM
To: [email-masked]
Subject: COPS-TLS extensions

Hello

Many thanks

---

From: "Kulkarni, Amol" <[email-masked]>
Date: Wed, 30 Jul 2003 16:15:12 -0700

Forwarding to the list for comments.

Amol

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2003 8:10 PM
To: Kulkarni, Amol
Cc: [email-masked]
Subject: RE: COPS-TLS extensions

Hello

The first extension is a "Session Re-Negotiation Timer 
Object". It consists of a 2 byte field indicating the 
duration after which a TLS session must be renegotiated 
between PEP and PDP. It also consists of a single byte flag 
that indicates if session re-use is permitted. The object 
would be appended to a Client-Accept message sent from the 
TLS enabled PDP.

The second is a "Session Re-Negotiation Required" message. 
This will be a new COPS message ( arbitrary opcode ) that 
contains a Session Re-Negotiation Timer Object. It will be 
issued by the PDP when TLS re-keying must be performed 
within the bounds of the time limit set in the initial 
Session Re-Negotiation object in the Client-Accept. It would 
be issued in the case that keying material is/may be 
compromised, and immediate rekeying is required. 

The final ( largely experimental ) extension is 
a "Enable/Disable Cipher Mode" message. It will consist of a 
new object that consists of 2 byte fields. The first field 
identifies a COPS message op-code, the second is a flag with 
values 0/1. The idea of the message is that it will be 
issued by either a PEP or PDP prior to sending, for example, 
a Report-State message that contains significant amounts of 
data ( 10's of MBs e.g. a large firewall log ). When the 
flag is set to 1, all subsequent COPS message that match the 
designated opcode will not be encrypted ( i.e a TLS 
handshake will be performed to disable encryption ). When it 
is set to 0, only the next COPS message that matches the 
opcode will not be encrypted. The idea will be to reduce 
processing requirements on low powered devices or heavy 
burdened PDPs when sending or receiving large amounts of 
data. e.g for a small mobile PEP device that uses COPS-PR to 
obtain its firewall policies, it may be necessary to have 
policy decisions encrypted but large report state messages 
can be left in plain text form.