Subject: [AAA-WG]: Issue 223: Why require CMS to send it's expected AVPs?

From: Pat Calhoun <[email-masked]>
Date: Tue, 6 Nov 2001 17:07:28 -0800

All,

Issue 221 states that perhaps since each AVP is defined as being possibly
signed and/or encrypted, perhaps it doesn't make sense to also require two
peers to exchange their local policy. If the policy is set to the AVPs
definitions, then interoperability is guaranteed.

Here is my proposal to resolve this issue, but I would like WG consensus
on what appears to be a massive simplification in both the operation and
the configuration of CMS.

Removed the Expected-Signed-AVP, Expected-Encrypted-AVP and AVP-Code AVPs 
and removed the relevant text in section 3.1. Add the following text to 
section 3.1:

"  Once the DSA is in place, any Diameter messages exchanged between the
   two peers MUST sign any AVPs whose definition states that the 'P' bit 
   may be set. Furthermore, these peers MUST encrypt any AVPs whose definition
   states that it may be encrypted."

Thoughts?

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 07 Nov 2001 09:12:58 +0100

>    states that it may be encrypted."

I think it's a fine simplification. I vote for it

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
  Ombú 3, 10th. 28045 Madrid - SPAIN -

---

From: Mark Eklund <[email-masked]>
Date: Wed, 7 Nov 2001 10:16:45 -0500

Pat,

With this it is not possible to send signed, but not encrypted AVPs.
Is this intentional?

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 7 Nov 2001 07:12:08 -0800

> With this it is not possible to send signed, but not encrypted AVPs.

Not directly, but a side effect of making such a change. Either one implements
a policy for each AVP in the protocol (the old way - and rather ugly and
complex), or a using the AVP definition instead. 

Any other thoughts on how to fix this? Otherwise, we need to go back to the
old way where one provides its AVP security policy (one by one).

PatC

---

From: Don Zick <[email-masked]>
Date: Wed, 07 Nov 2001 13:51:03 -0500

What if instead of having the Expected-Signed-AVP and Expected-Encrypted-AVP AVPS, we
have an ExpectedSecurity AVP that indicates if encryption and/or signing is expected?
If encryption is expected, all AVPs that can be encrypted are.  If signing is
expected, all AVPs that can be signed are.

Don

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 7 Nov 2001 11:17:15 -0800

I suppose that could work.

PatC

---

From: Don Zick <[email-masked]>
Date: Wed, 07 Nov 2001 14:46:28 -0500

After thinking about it a little bit, I guess my idea about the ExpectedSecurity AVP
probably doesn't do what we want.  It may be that messages of different types will have
different requirements.  For instance, you might want accounting messages signed and
authentication messages encrypted.

Don

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 7 Nov 2001 11:54:23 -0800

right, and then we are back to the original draft, except even that one didn't
provide granularity at the application level, but rather at a generic AVP level.

PatC