Subject: [AAA-WG]: Issue about clarifying PDS/DSA roles in CMS

From: Jari Arkko <[email-masked]>
Date: Sun, 10 Feb 2002 18:26:32 +0200

Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: Feb 10, 2002
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03003.html
Document: cms
Comment type: E/T
Priority: 2
Section: 1, 1.3, 7.1
Rationale/Explanation of issue:

People who have read the CMS document do not clearly understand
that PDS mechanisms are not intended to create actual security
associations, but just to offload the computations to someone else.

Secondly, the document does not explain what to do in case
NO_CMS_THROUGH_PROXY is maliciously returned from somewhere
else than in our own domain.

Thirdly, there's some spelling problems.

Requested change:

Change

 > This specification contains two different set of messages. The DSA
 > messages are used to establish a security assocation, while the PDS
 > messages are used to request that a security association be
 > established by a third party.

to

   This specification contains two different set of messages. The DSA
   messages are used to establish a security assocation, while the PDS
   messages are used to request that a security association be
   established by a third party. The security association established using
   DSA is used end-to-end for Diameter signaling, even through proxies that
   may exist in between. In constrast, where PDS messages are used, Diameter
   signaling is protected as usual only hop-by-hop between the client and
   the proxy handling CMS security on its behalf. From there onwards to
   the Diameter server, end-to-end protection is then used.

Also in 1.3, "recelived" => "received". And just before the end of
1.3, the last "MAY" => "might".

In 1.3, just before "If a DSA for a given realm cannot be established...",
add a new paragraph:

   A proxy MAY both allow CMS security through itself and it
   can offer CMS services to the clients connecting to it. This
   would be useful in networks where some clients wish to use
   CMS security themselves, and some others need the proxy to
   assist them. However, it is necessary to prevent misconfigured
   clients from inappropriately sending PDS messages to nodes
   further onwards in the network, as this would leaeve the
   Diameter messaging without CMS protection when it leaves the
   proxy. For this reason, the DIAMETER_NO_CLEARTEXT_THROUGH_PROXY
   MUST be returned for PDS messages where Destination-Realm
   is not the proxy itself. This also ensures that rogue nodes
   further onwards in the network can not return DIAMETER_NO_CMS_THROUGH_PROXY
   in an attempt to bypass security mechanisms.

And then add to section 7.1:

   DIAMETER_NO_CMS_THROUGH_PROXY     4014

      This error code is returned when a non-transparent proxy
      receives an PDSR message to Destination-Realm that is
      not the proxy itself, and the proxy requires CMS security
      to be applied for all traffic leaving it.