[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: COPS-PR security general issues
The basic integrity mechanisms of the COPS protocol are required to be
implemented, thus ensuring they will be universally available... but are
optionally used. So this means other security mechanisms can be used instead
of or to augment the integrity object. For privately exchanging information
using COPS, TLS/SSL is the preferred security mechanism since COPS already
runs over TCP. Specific client-types can be defined that *require* a
specific additional security mechanism must be used, such as TLS. This is
done by simply stating as much in the security considerations section of the
corresponding document.
Given TLS, do you see any reason to implement per-attribute security via
Diffie-Hellman exchanges or some other mechanism? TLS seems more than
sufficient for COPS messaging given the persistent TCP connection & single
master control.
-Dave
> -----Original Message-----
> From: Moisand, Jerome [mailto:jmoisand@unispherenetworks.com]
> Sent: Wednesday, June 13, 2001 1:54 PM
> To: 'IPSEC-POLICY (E-mail)'; 'RAP (E-mail)'
> Subject: RE: COPS-PR security general issues
>
>
>
> Sorry if it's a duplicate, sounds that I got filtered first
> time I sent this
> e-mail.
>
> Tx
> Jerome
>
> -----Original Message-----
> From: Moisand, Jerome
> Sent: Wednesday, June 13, 2001 11:19 AM
> To: 'MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail);
> RAP (E-mail)
> Subject: RE: COPS-PR security general issues
>
>
>
> 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
>
>
>
>