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

From: "Martin Julien (ECE)" <[email-masked]>
Date: Fri, 19 Jan 2001 08:46:13 +0100

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
>

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 23 Jan 2001 18:15:10 +0530 (IST)

hi!

   End to End security would require three basic components

 1> AVP integrity protection - Select AVPs that need to be inspected by
    intermediate hops but need to be protected against modification
    by intermediate proxies can be integrity protected. The MIC on these
    AVPs would be generated using the end to end key.

 2> AVP encryption - Select AVPs that need to be encrypted can be encrypted
    end to end using the end to end key.

 3> e2e authetication - I am not sure whether per AVP authentication 
    (or Grouped-AVP) would be very efficient since authentication tokens 
    need to be generated and need to carried back and forth. Infact if
    the end to end peers are authenticated and they use a negotiated key to 
    secure AVPs there wouldnot be a need to authenticate individual AVPs. 
    There would be only a need to mutually authenticate the key negotiation
    exchange (initial Request-Response) between the end to end diameter 
    peers.

  kaushik!