Subject: [AAA-WG]: Additional cms issues

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Feb 2002 16:59:06 +0000

Folks,

While *still* attempting to catch up on this mailing list, I've 
come across the following, hopefully easy to handle, CMS issues.
Let me know if you disagree with the resolutions (ideally this
week).

Stephen.

-- 
____________________________________________________________
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

Submitter name: Stephen Farrell
Submitter email address: [email-masked]
Date first submitted: 2002-02-26
Reference:
Document: cms
Comment type: E
Priority: 1
Section: 1.0 & others

Rationale/Explanation of issue:

The term non-repudiation has a long and convoluted history
in the PKI community. IMO, its use has generally confused 
things - something we don't want here. I think that what
we are really required to provide is data origin authentication,
which is both clear and is something that signatures do
provide nicely.

Requested changes:

s/non-repudiation/data origin authentication/g

Submitter name: Stephen Farrell
Submitter email address: [email-masked]
Date first submitted: 2002-02-26
Reference:
Document: cms
Comment type: T
Priority: S
Section: 6.0, 6.2

Rationale/Explanation of issue:

CMS-Encrypted-Data can be multivalued, so OctetString is
the wrong type for this AVP.

Requested changes:

s/OctetString/Grouped/g

Submitter name: Stephen Farrell
Submitter email address: [email-masked]
Date first submitted: 2002-02-26
Reference:
Document: cms
Comment type: T
Priority: S
Section: 6.8

Rationale/Explanation of issue:

CA-Chain-AVP has a bunch of certs, but the spec doesn't say
in what format. The usual thing here is to support the
CMS degenerate form of SignedData, known as a certs-only
message.

Requested changes:

Add:

   The OctetString contains a CMS "certs-only" message.

Submitter name: Stephen Farrell
Submitter email address: [email-masked]
Date first submitted: 2002-02-26
Reference:
Document: cms
Comment type: T
Priority: 1
Section: 1.3

Rationale/Explanation of issue:

Section 1.3 (2nd para) says:

"Therefore proxy agents either MUST NOT modify protected AVPs or
else MUST NOT allow the DSA to be established."

This seems overly restrictive, quite hard to implement and of
little value esp since we say that if a signature is present
then don't mess with AVPs.

Later on the same section says:

"Although the proxy agent MAY receive many PDSRs from access 
devices, only one DSA per realm MUST be established."

This seems both overly prescriptive and restrictive.

Requested changes:

Delete first sentence and change MUST -> MAY in 2nd case.

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 26 Feb 2002 19:11:50 +0200

> s/non-repudiation/data origin authentication/g

Yes.

> s/OctetString/Grouped/g

Yes.

>    The OctetString contains a CMS "certs-only" message.

Yes.

> then don't mess with AVPs.

This I don't understand. If the proxy has an intent to sometimes
modify AVPs that have been specified as encrypted/signed
in our specs, then it MUST NOT modify those AVPs. Or else
it simply refuses to let DSAR through, and establishes its own
end-to-end security association.

> Change MUST -> MAY.

Yes.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Feb 2002 17:29:18 +0000

Jari,

> This I don't understand. 

Huh? Do you not understand my problem or the text (if the
latter, then we're in the same boat:-).

> If the proxy has an intent to sometimes

I *think* that's a restatment of the sentence that causes me 
a problem.

Is it ok for me to delete the offending sentence?

Stephen.

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 26 Feb 2002 19:31:39 +0200

> latter, then we're in the same boat:-).

I do understand the text, but not your problem. But I must
be missing something. 

> Is it ok for me to delete the offending sentence?

Here's the two issues that I didn't understand in your
problem:

1) Why would we need to modify AVPs that have been
signed? It's going to fail anyway.

2) What is the implementation difficulty of not modifying
those AVPs?

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Feb 2002 17:51:11 +0000

Jari,

> I do understand the text, but not your problem. But I must

My problem is that I find the quoted sentence confusing and
useless. I'm definitely missing something, if the sentence
belongs where it is.

> else MUST NOT allow the DSA to be established."

Given that there can only be a signed AVP is there's a 
CMS-Signed-Data AVP in the message and that signed AVPs always 
have the "P" bit set then a proxy agent can always tell what not 
to mess with. So I don't see any need to say "don't mess" again.

Following on from that, I see no need for a proxy to disallow 
DSA establishment just because it might sometime want to mess
with signed stuff. Is there such a need? If so, under what 
circumstances?

> signed? It's going to fail anyway.

I don't know & agree, in that order. I want to loose that text.

> 2) What is the implementation difficulty of not modifying

Huh? The fact that follow-on questions like that crop up is 

> > > Is it ok for me to delete the offending sentence?

:-)

Stephen.

---

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

> to mess with. So I don't see any need to say "don't mess" again.

Ok, now I think I understand this part...

> with signed stuff. Is there such a need? If so, under what 

Well, the first paragraph of 1.3 talks about cases where the
proxy agent wants to implement policy or modify potentially
harm-causing AVPs.  Assuming this is a real need, imagine
a network scenario wher a new NAS is brought to the network,
and since the operator didn't bother configuring it too much,
it tries to establish a DSA to the home AAA server. At this
point all policy management and harm-prevention stops,
because the NAS happened to establish a DSA of its
own. Don't we need something in the proxy agent to catch
the DSA establishment attempt? Isn't this what
DIAMETER_NO_CMS_THROUGH_PROXY is for?

Jari

---

From: David Spence <[email-masked]>
Date: Tue, 26 Feb 2002 16:11:20 -0500

Jari Arkko wrote:
>... 
>... 

No!

For reasons I explained privately to Stephen, Octet String is correct;
Grouped is incorrect.

From original message:
>...
>...

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Feb 2002 13:57:22 +0000

David is right. You include many AVPs when necessary rather
than one AVP.

Stephen.