Subject: RE: Requirements for remote path processing services

From: Michael Zolotarev <[email-masked]>
Date: Wed, 31 May 2000 15:04:20 +1000

Andy,

to me, the obvious way of using the RPPS to validate ACs is to validate the
signer's ACA's certificate. The rest - policy, roles, etc - really belongs
to the AC's RP (which is an access control server itself, as you have
correctly mentioned). 
Therefore, the request from the RPPS client would be "Is that *ACA* cert
valid for me?".

I'd say that this is the only way one can use a general purpose RPPS box for
ACs.

Michael

> -----Original Message-----
> From: Andy Dowling [mailto:[email-masked]]
> Sent: Monday, May 29, 2000 9:02 PM
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: Re: Requirements for remote path processing services
> 
> 
> Paul + co.,
> 
> Having read your post, I was just wondering if these remote 
> path processing
> services could be applied to ACs for authorisation purposes? I've put
> together a few points on the subject (see below).
> 
> Comments would be appreciated.
> 
> Regards,
> 
> Andy
> 
> 
> 
> 1) OVERVIEW
> 
> In addition to remote path processing services:
> 
> a) delegated path construction
> b) delegated path verification
> c) trust and policy centralisation
> 
> that apply to public key certificates, there may be scope for
> the application of these services to authorisation-related 
> certificates
> i.e. Attribute Certificates could be verified remotely by a single
> trusted entity, and this would bring the benefits of centralised
> trust/policy management and simpler clients.
> 
> 
> 2) MOTIVATION
> 
> Firstly, let's present some arguments *against* introducing remote AC
> validation:
> 
> a) The current profile for AC validation is relatively simpler than
>    that of PKC validation:
> 
>         a) AC chains are not used
>         b) AAControls is optional
>         c) AC revocation checking is optional
> 
>    Consequently, a very minimal (and conformant) AC validator can be
>    implemented and would be "lightweight" enough to provide 
> on clients.
> 
> b) AC validation for authorisation purposes is typically a server-side
>    operation anyway, and clients would hardly need to validate an AC.
> 
> 
> In response to argument (a):
> 
>      Whilst a client may indeed conform to the simplest 
> version of the AC
>      profile with a lightweight implementation, such an implementation
>      would have no control over which attributes can be 
> issued by which
>      authorities (AAControls), due to the lack of chain processing.
>      In addition, the client cannot safely validate long-lived ACs.
>      This is due to the lack of revocation processing.
> 
> In response to argument (b):
> 
>      Clients *may* need to validate ACs in the push model to
>      ensure the integrity of the AC before passing it on to other
>      servers. (Complications arise here when the AC is pushed to a
>      different "trust domain" where the AC validation policy differs
>      to that of the clients policy, so there's scope for 
> further study here)
> 
>      A client will need to validate an AC if it is used in 
> the making of
>      a client-side access decision. Scenarios in which a client-side
>      access decision would need to be made are:
> 
>             --> Checking the permissions of downloaded content:
>                 --> Has a piece of downloaded code have 
> execute permission
>                     from the system admin?
> 
>             --> Client-side content filtering:
>                  -> Checking if downloaded content has a 
> "rating" attribute
>                     (12, 15, 18, PG-13, NC-17, R, etc.)
> 
> 
> It is apparent that there is indeed a requirement for:
>        (a) clients to validate ACs
>        (b) AC validation to be performed "fully". That is, AAControls
>            and revocation checking should be done for 
> security reasons.
> 
> Given these requirements, it seems logical to migrate these 
> verification
> tasks to a dedicated AC validation server.
> 
> 
> 2) BENEFITS:
> 
> The benefits are the same as for remote PKC processing:
> 
> a) Centralised trust and policy for authorisation purposes
> 
>     (i)   Administrator(s) can say what AAs are trusted by 
> the enterprise
>     (ii)  Administrator(s) can implement complicated trust 
> management via
>                            AAControls and/or AC Chain validation
>     (iii) Administrator(s) can implement AC revocation checking
> 
> b) Simplified clients
>     (i)  No need for the client to implement any form of AC 
> verification,
>          path processing (for AAControls), LDAP/OCSP clients, etc.
> 
> c) Server-side caching to improve turnaround time on a 
> validation request
> 
> 
> 
> 
>