The Limited Production System:
Authentication and Authorization

Vance Vaughan
18 Sept 1998

Introduction and Purpose

The Limited Production System (LPS) is intended to provide access control to various network resources. Access control is commonly parsed into two parts. Authentication establishes who someone is. Once you have established who someone is, there is the question of what they are authorized to do:

Authentication + Authorization = Access Control

The LPS has several components which are discussed below:

• Public Key Infrastructure (PKI)
• Attribute Query Protocol (AQP) client
• Attribute server(s)

Public Key Infrastructure (PKI) - Authentication

The PKI is the "authentication" part of the puzzle. It will consist of a hierarchy of CA's, with a root CA at UCOP which will only certify other CA's: one per campus (and one at UCOP). The campus CA's will certify end-users, web servers, etc. The campus CA's are expected to conform to a policy. The policy specifies the content of certs issued to individuals: UCCerts. The campus CA's will be responsible for identifying certificate applicants, issuing (and renewing) certificates, revoking certificates.

The bottom line is that if someone presents you with a UCCert (and it checks out, hasn't been revoked, the person has the private key, etc.) then that person is authenticated - you know who that person is. The question of what he is able to do is the realm of authorization, which is covered below.

Implementation considerations:

• The initial rollout will consist of Netscape CA's. Some experimentation (eg the UCLA GTE prototype) is being conducted. UCOP is looking at IBM's vault registry product.
• Certificate revocation handling is an open question. But note that revocation will be an unusual circumstance. It will primarily be invoked in cases of compromise of the customers private key; it will NOT be invoked to reflect a change in status of the holder.

AQP Client and Attribute Servers - Authorization

Authorization is ultimately the responsibility of the application, which may have its own idiosyncratic rules to enforce. But some support for basic queries ("is the person identified by NetID xxx a student") should be provided by the system.

End user UCCerts will not contain attribute data. Rather, they will contain only a NetID (or CampusID), which can be used to obtain attributes via an AQP client call to an Attribute Server. How this is to work is the subject of a draft: Functional Specification for UCCAP Attribute Server and Attribute Query Protocol. However, that document doesn't answer the question "what is an application which is presented with a UCCert to do?" It is free to do as it pleases, but we intend to provide a model AQP client which applications can call and which will at least answer the question "is the person associated with NetID xxx a {student,faculty,staff, member of the community}". The remainder of this paper postulates some characteristics of the attribute servers and the interaction between the AQP client and the attribute servers.

There will be different attribute servers:

• There will be an attribute server at each campus and at UCOP (attributes.campus.edu):.
  • The campus attribute server will have access to at least the data from the UDir for members of the campus.
  • It may have access to additional data, eg people with a campus ID but no NetID and it could have course enrollment info for students, etc.
  • It will answer queries from an AQP client:
    • error status
    • yes/no
    • referral (a url)

• There will be a master attribute server (attributes.ucal.edu).
  • It will contain data for all valid NetIDs.
  • It could answer queries from an AQP client:
    • error status
    • yes/no
    • referral (a url)
  • It could just provide referral service:
    • error status
    • referral (a url)
  • And it might provide translation service:
    • Is there a NetID corresponding to this campus ID?

• There might be attribute servers that are specialized to the needs of specific applications.

The AQP client should:

• answer the query
• give an error response

The AQP client should take as input:

• the certificate (because it should unpack it to discover if there is a pointer to an attribute server in it so it might as well deal with it)
• the query (student, faculty, staff, member of community, others?)
• (optionally) an attribute server
• whether to look deeper than 1
• ???a certificate authorizing the app to do this lookup

The AQP client finds an attribute server as follows:

• (optionally) the attribute server that the application requested.
• ptr in cert
• attributes.campus.edu, attributes.ucal.edu

The AQP client then calls the Attribute Server.

The Attribute Server will do what it has to do (consult local DB's) to answer the query. It will return:

• error status
• yes/no
• referral (a url)

The AQP client then:

• if it got yes/no, it returns yes/no
• if it gets a referral and it was called with depth >1 it decrements depth and calls the referral attribute server.
• if it got an error, it depends on the error. For most errors, it will just return the error. However, if the error was "i couldn't find this NetID", then the AQP Client should try attributes.ucal.edu to get a referral to a campus (if depth >1).

Implementation considerations:

• We are contemplating using Netscape's LDAP directory server for the attribute server.
• UCOP, UCI, and UCLA are talking about implementation strategies.
• We're defining an http version of the AQP.

Conclusion

The authentication part of the puzzle is (comparatively) well understood and implementation is proceeding. The authorization part of the puzzle needs dialog. Comments should be emailed to the lists: auth-wg@ucop.edu and uccap-auth@cdl.ucop.edu.