Subject: RE: Requirements for remote path processing services

From: Ambarish Malpani <[email-masked]>
Date: Mon, 29 May 2000 11:27:33 -0700

Hi Andy,
    You could use the remote path processing server (RPPS) to verify
ACs, or even better, you could actually use it to authorize
certain user actions and avoid needing to deal with ACs at all!

In the case where you do trust the RPPS, the kind of query I expect
an application to send it, would be of the form:
"Can I trust this certificate to do the following action".

At that state, I would fully expect the RPPS to go out and figure
out what the attributes of the certificate are, so, as an
application, you can be completely relieved of the job of
processing ACs at all.

Does this make sense?
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Andy Dowling [mailto:[email-masked]]
> Sent: Monday, May 29, 2000 4:02 AM
> 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
> 
> 
> 
> 
>

---

From: "Andy Dowling" <[email-masked]>
Date: Tue, 30 May 2000 09:47:03 +0100

Hi Ambarish,

thanks for the prompt reply.

I can identify two distinct stages in the use of ACs for making an access
decision:

1) Verify/validate the AC in accordance with system trust policy.
2) Extract the attributes and make an access decision based on the
     "required" attributes, versus the attributes encoded in the AC.

Whilst delegating task (1) to RPPS is fine by me, I see task (2) as more of
a "local" action that would be made at the location of the resource/action
being requested. Hence, delegating this decision to a centralised server
seems like an unnecessary offload of the access decision. Whilst I can see
this working in the specific case where the access control rules for an
entire domain are defined centrally, I can't see this working for the
general case.

Another point to note is that ACs are not limited to more than just
authorisation and access control services. By separating the access decision
process from the underlying privilege representation (i.e. ACs), we are not
limiting RPPS to verifying ACs for authorisation purposes. Instead, we can
use RPPS solely for the validation of ACs, meaning that the client can then
extract the attributes and use them in local processing (for access control
purposes or otherwise).

Regards,

Andy

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 May 2000 11:47:13 +0100

Ambarish,

Though what you suggest is possible, I think its just not
in scope for PKIX. There are lots of reasons, but one is
that there's really no point in us attempting to define 
an authorization protocol that can *only* use PKI based 
authentication. If we omit requirements to do with other 
forms of authentication (e.g. Kerberos, OTP, RADIUS,...) 
then we're just not doing a good job. I can't see 
any way to interpret the PKIX charter to incorporate such 
(real) requirements. Maybe you should look to the AAA
WG to pursue this?

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com