[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: COPS-TLS extensions



Forwarding to the list for comments.

Amol

-----Original Message-----
From: geg01@uow.edu.au [mailto:geg01@uow.edu.au] 
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 
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.