RE: COPS-PR security general issues

["Moisand, Jerome" <jmoisand@unispherenetworks.com>]

I support the concern described by the e-mail quoted below, which resonates
quite well with what I heard from multiple service providers during
COPS-related discussions.

I would suggest that the topic is discussed during the next IETF meeting in
the context of the "rap" group since the point is essentially to secure the
COPS/COPS-PR interactions, irrespective of the type of policies being
managed.

In this context, among other alternatives, I would also suggest to discuss
the following internet-draft:
http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt

Tx
Jerome

=========================================== 
Jerome P. Moisand 
Senior Product Manager 
Unisphere Networks 
mailto:jmoisand@UnisphereNetworks.com 




-----Original Message-----
From: MORAND Pierrick FTRD/DMI/CAE
[mailto:pierrick.morand@rd.francetelecom.fr]
Sent: Thursday, May 31, 2001 8:08 AM
To: IPSEC-POLICY (E-mail); RAP (E-mail)
Cc: NOISETTE Yoann FTRD/DMI/CAE; RABOT Wilfrid FTRD/DMI/CAE
Subject: COPS-PR security general issues


We are currently working on the general theme of provisioning. We are
considering COPS-PR with attention and would bring to the attention of RAP
and IPSP experts the following remarks and questions with our apologizes if
these issues have already been debated.

In a general way, COPS-PR has been designed to provision configuration
policies for various functional domains such as IPSec, L2TP, MPLS, AAA,
Routing, TE ....

Considering for instance, IPSec, AAA and L2TP, provisioning of those
functions leads to exchange with the equipment sensitive information such as
shared secrets (L2TP-Tunnel-password, users password, radius secret and so
on).

Within COPS there is an optional security mechanisms, which only guarantees
the integrity of the COPS messages. There is no general mechanisms allowing
to cipher some particular sensitive fields.

Do these security issues shall conduct an implementer or an operator to
systematically make use of IPSec to secure exchanges between a PEP and a PDP
so that it becomes possible to provision sensitive security information
without having to defined ciphered fields in the PIBs for which no generic
mechanisms have currently been defined ?

If  IPSec is used to secure COPS-PR exchanges what would become the utility
of the integrity mechanisms defined within COPS and more especially when
used within COPS-PR ?

Additionally, the IPSec PIB which is currently in its definition phase,
allows to define IKE rules specifying pre-shared key as Ike proposal
authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with
presharedKey(1) as possible value]method but does not allow to provision
those secrets. This means that the provisioning of those secrets shall be
done by an other way and in that case advantages of COPS-PR in case of
pre-shared authentication becomes greatly reduced since this shall be
achieved by hand or using an other mechanism.

In a same way if L2TP or AAA PIBs were to be defined how secrets (and more
generally sensitive information) should be provisioned ? 
-In clear : not reasonable
-Ciphered : there is no generic mechanisms
-Protected by IPSec, SSL... : should work fine, but the RFC should precise
that usage of a particular client type, defining sensitive information MUST
make use of an external mechanisms in order to secure those sensitive
information..

To conclude it seams that we can have the two possible approaches in order
to allow the exchange of sensible security information between a PEP an a
PDP :
1-systematicaly make use of an underlying security layer (IPSec for
instance) to secure exchanges between PEP and PDP. In that case the COPS
integrity mechanism is no more necessary. This approach implies that the PEP
has to support a security communication layer which might not be the case in
all situation.
2-defines a generic COPS ciphering mechanism which allows to protect some
sensitive fields. Security is embedded in the COPS protocol and must be
supported.

If this issue was solved, could IPSP experts extend the PIB so that shared
secret can be exchanged or is the reason for which it is not currently
supported more fundamental ?

Thanks in advance for your answers and comments.

Pierrick Morand
france telecom R&D/DMI/SIR/IPI
Tel   : +33 2 31 75 91 79 -  Fax : +33 2 31 73 56 26
Email :pierrick.morand@francetelecom.com