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

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Oct 2001 18:58:01 +0100

Pat's hassling me to help tidy up some issues that are stragglers:-)

The text for #185 is below for reference.

I think we can close this if we add the following clarification
at the end of either section 1.2 or 1.5:

"This specification does NOT REQUIRE that a DSA be established
before the CMS AVPs are used. For example, a Diameter agent
could sign or countersign certain messages as they pass by, or 
a node might add an additional recipient to a CMS-Encrypted-Data
for archival purposes."

Regards,
Stephen.

Issue 185: CMS-protected AVPs outside a DSA 
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. 

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Don Zick <[email-masked]>
Date: Thu, 25 Oct 2001 13:14:47 -0400

Hi Stephen,

> a node might add an additional recipient to a CMS-Encrypted-Data

I don't follow why a node might add an additional recipient to a
CMS-Encrypted-Data AVP.  How can anyone but the originally intended
recipient of a CMS-Encrypted-Data AVP have the necessary key information
to interpret the AVP?

Thanks,
Don

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Oct 2001 18:30:17 +0100

Hi Don,

> CMS-Encrypted-Data AVP.  

Why: E.g. say if *I* want someone to archive all the stuff *I* 
encrypt. Not a super example, though I agree.

> How can anyone but the originally intended

How: Of course not anyone can do this, only someone with access to
the clear text, which basically means the originating node, in 
which case its easy (just add another RecipientInfo).

Cheers,
Stephen.