Subject: AAA-WG: RE: Making the hard choices on AAA security

From: "Martin Julien (ECE)" <[email-masked]>
Date: Fri, 19 Jan 2001 15:02:55 +0100

Pat, Stephen,

I guess the easy answer to this is to use signed-only CMS-Data AVP, allowing the Result-Code AVP to be protected (P flag set) in the case of rejection only from a Home or Proxy server, right? Then, in the case where the Home server accept the request, the proxy could still reject it based on local policies. However, I don´t think it fits into a clean solution. Another thread in this ML talks about MRI and Result-Codes from Extension Reply/Answer, and I need to figure out where it is going before coming up with something better.

Also, if I think of an example in which the request is rejected and the Result-Code AVP authenticated by a CMS-Data AVP, I wonder if the proxy could still remove the CMS-Data AVP and replace the Result-Code AVP for a successful answer? I guess, in the case of e2e security, the originating servers should always be expecting a CMS-Data AVP from servers which are located on the other side of untrusted proxies, otherwise messages could be an indication of fraudulent activities. I think there can not be more than 1 CMS-Data AVP per message, which means that it would be difficult to mix signed-only and encrypted data. Since there is nothing in the Base and Extension protocols about it (as far as I know), maybe some clarification in the Strong Security Extension would be needed. I guess the servers need to define some special information in their routing table about trusted and untrusted servers and local policies for handling the validation of the messages. I might be missing some fundamental knowledge here, so I'd appreciate if you could answer this.

I think I understand the requirement of simplicity and lightweight... ;-)

Martin

-----Original Message-----
From: Martin Julien (ECE) [mailto:[email-masked]]
Sent: Friday, January 19, 2001 8:46 AM
To: [email-masked]'; [email-masked]'
Subject: AAA-WG: RE: Making the hard choices on AAA security

I think that authentication on an AVP basis could be an excellent generic solution, and probably not as costly as encryption. However, should it be also allowed to authenticate a group of AVPs, since it seems that the Grouped-AVP AVP, which could contain the group ICV, is gone by now in the -18 document?

Martin

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 7:00 PM
To: Martin Julien (ECE); Steven Glass - Solaris Software;
[email-masked]'
Cc: [email-masked]; Alain Zahm; Bernard Aboba
Subject: RE: Making the hard choices on AAA security

For proxies that wish to maintain state information, not having access
to the result code would be a problem.

Perhaps e2e authenticated, but not encrypted.

PatC
>Steven,
>
>Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e,
>using the Strong Security extension of course, which would prevent proxies to
>play around with its content when not allowed by the server?
>
>Martin
>
>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]]
>Sent: Thursday, January 18, 2001 11:16 AM
>To: Steven Glass - Solaris Software
>Cc: Bernard Aboba; Alain Zahm; [email-masked]
>Subject: Re: Making the hard choices on AAA security
>
>
>
>
>Steven Glass - Solaris Software wrote:
>> 
>> >
>> >
>> > > Bernard Aboba wrote:
>> > >
>> > > A proxy can change an Access-Accept into an Access-Reject under the guise
>of "policy". However, an
>> > > Access-Reject should never be changed to an Access-Accept. A good question
>is how this could be
>> > > enforced, using any of the solutions that have been proposed.
>> >
>> > Not sure it could...
>> 
>>     Maybe not from the solutions proposed...
>
>Just for clarity, CMS, Kerberos and any other self-respecting 
>e2e security solution will offer e2e data integrity. The "not 
>sure" etc. refers to allowing one type of change and 
>preventing/detecting another, not to simple integrity.
>
>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
>