Subject: [AAA-WG]: [issue] CMS-protected AVPs outside a DSA

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 24 Sep 2001 12:29:05 +0200

Submitter name: Miguel A. Monjas
Submitter email address: [email-masked] 
Date first submitted: 2001-09-24
Reference: 
Document: CMS-02
Comment type: T
Priority: 1
Section: 
Rationale/Explanation of issue: 

The CMS application comprises two main "features" (as described in
section 2.0): the security feature, which comprises the messages
necessary for establishing security associations and the AVPs needed
to protect other AVPs; and the proxy feature, made up of the messages
that are used to ask a proxy to establish a security association.

On the other hand, the CMS draft begins by describing how a security
association can be established (sections 1.1 and 1.2). It might looks
like as if the CMS draft states that a security association is needed
to exchange protected AVPs. But it doesn't actually say it.

Another points:

- The definition of CMS-Signed-Data AVP (section 6.1) introduces the
concept of countersignatures. This attribute allows any Diameter peer
to add its own digital signature to an existing CMS-Signed-Data AVPs
(but always on the same set of AVPs, the ones with its protection bit
set). As far as I understand, this situation could happen when a
broker signs AVPs in given Diameter messages that traverse through it.
Section 1.3 also describes a "business model" in which two Diameter
nodes signs "in parallel" accounting AVPs. It is supposed that those
both parties are the participants of a DSA (according to figure 4).
The base specification also talks about AVPs being signed by two
parties (sections 9.5 and 9.7.1) usually to be forwarded to a third
party with settlement purposes (however, it isn't said whether those
AVPs would be forwarded using new Diameter messsages). Discussion on
issue #150 emphasizes that a digital signature has no actual receiver
(that is, a Diameter node can sign anything withour a explicit request
within the framework of an established DSA)

- The definition of CMS-Encrypted-Data AVP (section 6.2) reviews the
concept of RecipientInfo, an attribute of the CMS structure
EnvelopedData that allows to encrypt a given set of AVPs for different
receivers using an only CMS-Encrypted-Data AVP. Discussion on issue
#150 also introduces an example in which a Diameter node has to
encrypt some (different) AVPs to two different receivers. Section 6.2
(proposed) says that:

   If the recipient is not specified in a RecipientInfo, it MAY
   choose to process the message or return an answer with the
   Result-Code AVP set to DIAMETER_NO_DSA_RECIPIENT"

that is, a node can receive a CMS-Encrypted-Data AVP with a receiver
different from itself.

- As a result of "Questions about AVPs ocurrence" series, it was
stated that "The DSAR message MUST NOT be used simply as a convenient
certificate distribution protocol without establishing a DSA" (section
4.1). What might imply that a DSA is necessary to include a CMS-Cert
AVP. However, section 6.1.7 in base protocol states that:

   Redirector agents MAY also include the certificate of the servers
in
   the Redirect-Host AVP(s). These certificates are encapsulated in a
   CMS-Cert AVP [11].

and the same in section 1.3 of CMS:

   the redirect agent to retrieve the necessary information for it to
   communicate directly with the home server, which MAY include the
   home server's certificates.

Requested change: 

a) Clarifying whether CMS-* (that is, CMS-Signed-Data,
CMS-Encrypted-Data and CMS-Cert) may be exchanged without an
established DSA between the peers. If so, introducing a brief
description of scenarios in which no previous DSA is needed (that is,
that a node can sign of encrypt AVPs according only to its local
policy and not to an explicit DSA)

b) Whenever CMS is used in the base draft, describing that
functionality in the CMS draft.

Regards

  // M.A.

-- 
  Miguel Angel Monjas Llorente
  Systems Engineer, GSM/UMTS Systems Management
  Ericsson España, S.A. (EEM) UMTS/GSM Databases
  Tel: +34 91 3393605                 Mob: +34 629 570196
  <mailto:[email-masked]>  Fax: +34 91 3392538
  Retama 1, 4th. 28045 Madrid - SPAIN -

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 24 Sep 2001 16:40:09 +0200

> policy and not to an explicit DSA)

BTW, if it's allowed to include additional "out-of-DSA" signatures, it
will supposed that an appropriate digital signature must be include
and that (it the destination node supports validation checks) the
certificate must be validated (since no TTL is available).

  // M.A.

  Ombú 3, 10th. 28045 Madrid - SPAIN -