Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat

From: William Bulley <[email-masked]>
Date: Wed, 29 May 2002 11:20:00 -0400

According to [email-masked]:
> 
> Do you propose to strike the 2nd part of the text entirely (that is OK for me) or
> modifying it to be something like:
> 
> 	The Accounting-Answer command contains the same Session-Id and 
> 	includes the the usage AVPs only if the NSA specifically 
> 	requests that they be included, such as by including the CMS-
> 	DATA AVP.

s/NSA/NAS/

otherwise we are in deep doo-doo...   ;^)

Regards,

web...

-- 
William Bulley                     Email: [email-masked]
Merit Network Inc.                 Ann Arbor, Michigan

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 May 2002 22:34:51 +0300

I agree that we should avoid bloat.

The question is, if we will avoid it only most of the time, or all of the time.
John's suggested text deals with the case that the NAS [or the NSA -- are you
sure John you don't work for them? ;-) ] indicates its need through either using
or not using the CMS AVPs. This is the current approach, but it seems a bit
at odds with the regular CMS 'P' and 'MAY ENCR' approach with fixed policies.
There are AVPs that have a 'P' and 'MAY ENCR' in every ACR/ACA command, so
it would seem that the CMS AVPs are needed in any case. Local configurations
may indicate that CMS should be turned off for some communications, though.

So indicating the need for the CMS AVPs in the response is one problem.
Here we have the following alternatives: 1) current text, clarify that
this rule takes precedence over the regular P/ENCR rules or 2) simply use
the P/ENCR rules.

Then there is another problem. What should go into the response, and
how should the signature be made? Here we have the following alternatives:
1) If CMS is needed at all, copy all AVPs to the response. 2) Decide that
we don't need this function i.e. no usage AVP copying at all and no
signatures either. 3) Invent some special rules in CMS so that CMS-Signed-Data
AVP can sign even AVPs that are omitted from the response. 4) A "hash" AVP
is added by the NAS when it uses CMS, containing a hash of the AVPs
protected by CMS. The server is then required to copy this AVP back,
and per P/ENCR rules sign it.

Personally, 2+4 would be the cleanest technical solution. I can live
with 1+1 (John's text) to avoid too many changes.

Jari

---

From: Johan Johansson <[email-masked]>
Date: Wed, 29 May 2002 23:56:06 +0200

I'm have a shady understanding of how CMS works at best, so please bear 
with me if I'm completely off target. If you are using CMS, wouldn't the 
simple fact that the ACR checked out at the accounting server by itself 
mean that it was transfered correctly and the ACA with a 
DIAMETER_SUCCESS Result-Code be the receipt that it did?

If this is not the case then I'd prefer your solutions in the order 4, 
2, 1. I can't really comment on number 3.

j

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 May 2002 01:08:37 +0300

> DIAMETER_SUCCESS Result-Code be the receipt that it did?

Yes, though for the purposes of non-repudiation a "plaintext" ACA SUCCESS
will not be helpful. That is, I send you something encrypted with your
PK and signed by my PK. You will be able to conclusively show that I
wrote the message. But I will not be able to show that you received
it.

Adding CMS on the ACA SUCCESS helps a bit, because now I can show
you received something for session ID X. However, I still can't
prove you received exactly those values that I sent you, because
I could be lying later and claiming that I used the session ID
with some other AVP values.

Finally, adding either the usage AVPs, or a hash of them in the
ACA SUCCESS, protected by CMS, will help me to show that you
actually did receive the AVPs in question.

Whether we need this function is another debate.

Jari

---

From: Johan Johansson <[email-masked]>
Date: Thu, 30 May 2002 00:59:07 +0200

Jari Arkko wrote:

> Johan Johansson wrote:
>
>> I'm have a shady understanding of how CMS works at best, so please 
>> bear with me if I'm completely off target. If you are using CMS, 
>> wouldn't the simple fact that the ACR checked out at the accounting 
>> server by itself mean that it was transfered correctly and the ACA 
>> with a DIAMETER_SUCCESS Result-Code be the receipt that it did?
>
>

True. And we all seem to agree that without CMS the same goes for 
echoing back the usage AVPs.

> with some other AVP values.

Yes, I think I understand now. You need to send something back that 
takes the sent values into account for non-repudiation purposes. Thank 
you for your explanation. So while the receiving end can prove that it 
received something from me and that it received the values I sent, I 
still can't prove that it received the values that I sent.

> Whether we need this function is another debate.

Non-repudiation seems near-essential on any AAA protocol's feature list. 
Using a hash seems lean, sufficient and in line with solutions to 
similar problems.

j