alex reid, aarnet australian access federation; 21-may-08 the australian access federation terena...

Alex Reid, AARNetAustralian Access Federation; 21-May-08

The Australian Access Federation

TERENA Networking Conference 2008

Alex ReidDirector, eResearch/Middleware

AARNet


Agenda

The ContextAAF OverviewThe Shibboleth PartThe PKI Part

ModelCertificate ManagementSecurity Levels, LoAs

Progress Report


Only a Selection…

To explain all nature is too difficult a task for any one man or even for any one age. `Tis much better to do a little with certainty, and leave the rest for others that come after you, than to explain all things.

– Sir Isaac Newton

3


Context: Australia in the World

4


Context: Australia

5


Context: HE/Research Infrastructure Backing Australia’s Ability (BAA)

Systemic Infrastructure Initiative (SII)Meta-Access Management System (MAMS)PKI SystemMiddleware Action Plan & Strategy (MAPS)

National Collaborative Research Infrastructure Strategy (NCRIS)8 discipline areasPlatforms for Collaboration

Network Federation Australian Research Collaboration Service (ARCS) Australian National Data Service (ANDS) National Computational Infrastructure (NCI)

6


AAF Overview Players: CAUDIT, AusCERT (Uni of Queensland),

Macquarie University, AARNet MAPS Funding:

DevelopmentOperation

Management & Legal frameworks Scope:

HE/ResearchOther education – later Interaction with other entities:

Government – laterInternational (New Zealand, maybe others later)

7


Other Related Projects People Picker (federated directory) ShibPAC – Shib-enabled command line access to HPC

facilities (eg for ssh or portal access) Pluggable AuthN Module (PAM) – needs to be installed

for each HPC (takes username/password) FAPPS – Federated Account Approval & Provisioning

System SICS – Shibboleth Integrated Credential Service (meets

IGTF’s Member Integrated Credential Service profile) Cross-certification with HEBCA

8


Shibboleth Part MAMS – Meta Access Management System Testbed Federation Mini-grant scheme

Id ProvidersService Providers

Operation:Test operation (full production but no agreements) since 2006Shibboleth 1.3WAYF operated by AARNet, resilient configuration20 universities (incl. 2 form NZ), 23 other entities, participating at

level-2 (more at level-1, purely test) – 700,000 identitiesAdditional features: ShARPE, Autograph, IAMSuite, etc

9


Shibbolised Services (SPs) ‘Fez’, the Fedora GUI that provides access to UQ’s repository and eSpace. Access to domestic and international users of QUT’s e-Grad School services. Shibbolising GU’s Wiki. GU’s Digital-information sharing services (e-Prints, e-Science Data, and CQA

Student Artworks). Access to the ENUM registration service (AARNet). Grid-enabled Archive of Nanostructural Imagery (GRANI) project services. Grid Portal ShibGridSphere & ShibMyProxy – secure testbed for Grid services

(MonashU). eLecture repository (DeakinU). ShibbGridSphere portal access for the LIGO (laser) group to data repository

and HPC (MelbourneU). Reciprocal borrowing among 5 WA university libraries. Online Librarian (MurdochU + MacquarieU), Plone and SRB (JCU).

10


The Federation Schema Supplanting old auEduPerson schema Derived from Use Cases International corresponding members Working Party locked in a room Draws from existing schemas:

Person, eduPerson, organizationalPerson, inetOrgPerson, SCHAC

3 Groupings: Core, Recommended, Other Includes HE as well as Research/Grid community Core attributes:

auEduPersonPersistentID -> auEduPersonSharedTokendisplayName eduPersonAffiliation eduPersonEntitlement eduPersonScopedAffiliation eduPersonTargetedID

11


PKI Part Origins Rationale Uses

GridsServer certificates (including Shibboleth)Client certificates (all staff & students??)

Structure Browser recognition of root certificate

Webtrust AuditMicrosoft, Apple, Mozilla

Certificate service to others – maybe

12


Original PKI Objectives Sharing resources between universities, eg course material Need for graduated degrees of security Digitally signing & encrypting documents Lightweight nature of trust relationship compared with

Shibboleth Lower cost than full Shibboleth implementation Authentication, authorisation, integrity, confidentiality, non-

repudiation Sample Use Cases:

Official emails to students [signing]Official personnel emails to staff [signing & encrypting]Students submitting essays, etc [signing]Researcher access to remote resources (eg Grid computing)

13


PKI Arrangements Pilot developed by AusCERT 2005 Policies under development WebTrust Audit:

Resources to carry out workExpert advice on system setupCost of setup (highly secure, resilient)Cost of initial auditCost of annual audits

Certificate Management Systems:Central CA software Institutional RA software

14


AAF PKI Model

15

CA Level CA Level CA Level

Level 3CA Level InstitutionsCA Level

InstitutionsCA Level

VO IDP

Policy ManagementAuthority (PMA)

OldCA

CA Level

AusCERTCA Level 2

AusCERTCA Level 3

AusCERTCA Level 4

GRID CAInstitutionsCA Level 1

Trust Fabric CA

RA RA RA

AusCERTRoot CA

OldCA

RA RA

AusCERTCA Level 1

AAF PKI Model

CA Level CA Level CA Level Institutions

1

RA RA

VO IDPServer CA Hosted CA

Level 1

HEBCA

FBCA

?


Certificate Management System Selection 23 criteria (17 mandatory, 6 desireable) Products considered: RSA CM, RedHat CS, OpenCA, EJBCA,

Microsoft Initially [Dec-07], RSA CM:

Common Criteria security evaluation – Evaluation Assurance Level 4 (EAL4) - see http://en.wikipedia.org/wiki/Evaluation_Assurance_Level as at 2007-12-07

Is in DSD Evaluated Product list It is believed that this product meets most of the technical requirements

outlined in Appendix A. Furthermore discussions with RSA have indicated that they are willing to customise aspects of their product to support the AAF PKI model

But on closer examination proved problematical

OpenCA failed on many fronts RedHat [Feb-08]: OSS in 2009, but not in the DSD Evaluated Product

list (EPL) [may impede cross-recognition with Aust Govt Gatekeeper]16


CMS Selection Criteria

17

Criteria Requirement

support the customised certificate profiles and extensions planned for AAF. Mandatorysupport hardware security modules listed in the DSD Evaluated Products List (EPL). Desirablesupport export of CRLs and CARLs to 3rd party directories (for example LDAP). Mandatorysupport multiple OCSP responders in load balanced and/or failover configuration. OCSP responders must be capable of utilizing hardware crypto-acceleration. OCSP responders must support queries about certificates issued by multiple CAs and issue valid responses (as specified in RFC 2560) signed by CA designated responder keys (authorised responders)

Mandatory

support digitally signed audit logs. Mandatorysupport digital certificate generation and management. MandatoryCommon Criteria EAL4+ certified or in the process of being certified. MandatoryEPL certified Desirablelocal and remote administration capability. Mandatorylocal and remote web-based administration. Desirabletoken management support for key archival and recovery Mandatorycapable of implementing the certification authority, registration authority, key recovery and validation authority roles. Mandatorycapable of enforcing operator role separation Mandatoryprovide scalability with multiple Registration Authorities for a CA. Desirablesupport SHA-256 and SHA-512 Mandatorysupport cryptographic elliptic curve standards proposed by NIST Desirablerun on Linux platform. Mandatorycapable of securely archiving and recovering encryption keys of users. Mandatorysupport deployment into separated network security zones for the CA and RA software components. The application should support network filtering between the zones and the wider network.

Mandatory

support PKI applications over multiple protocol interfaces such as LDAP, SSL-LDAP, HTTP, HTTPS, CMP and SCEP and also interoperates with other PKI-aware products.

Mandatory

support integration with FIPS 140-1 Level 3 -certified Hardware Security Modules (HSMs) Mandatoryinterface to allow bulk creation or revocation of certificates MandatoryAPI to allow automation of certain tasks and workflows Desirable


PKI Security Levels

18

Certificate Level

Description

Level 1

No proactive identity check provided to the RA. Identity information provided by a body that the RA has a trust relationship. Example: A student being enrolled in at least one subject is sufficient for the

certificate issuing however identity information has only been supplied by QTAC (or similar state body).

Level 2

Subject must provide proof of identity by appearing IN PERSON at the RA. Individual cannot provide the required 100 points of identification. Example: Short term contractors at an institution requiring access to PKI-protected

systems whose credentials are insufficient credentials to meet the 100 points check but can provide some credentials (e.g. drivers licence, credit card, etc).

Level 3

Subject must provide proof of identity by appearing IN PERSON at the RA. Individual must accrue at least 100 points of identity. Example: Foreign staff with valid passports and written references from acceptable

referees.

Level 4 Subject must provide the same information for Level 3 certification in addition to

character background check. For example a positive check is also conducted by an appropriate external agency.


Levels of Assurance Can we postpone the discussion on LoA until the

federation is launched? This could reduce complexity of initial implementation Upgrading the federation to a higher level of assurance

than the startup baseline may require new/updated agreements, extra costs to meet that baseline for ALL identities serviced by an IdP, and redeployment of technologyWill we fall under the footsteps of other federations that are now

struggling to retrofit LoAs?

Will federation members be happy to redeploy IdP and SPs later?

19


LoA Relationship to Other CAs

20

FBCA Certificate Levels

CAUDIT PKI Pilot

Australian Government Gatekeeper – Individual Certificate

Rudimentary Level 1 Grade 1

Basic Level 2 Grade 2

Medium Level 3 Grade 3

Not Applicable Level 4 Not Applicable

High Not Applicable Not Applicable


How to Set LoAs, if Deployed?

21


LoA – Current Issues What are the federation business drivers? What level of high value/sensitivity resources and

collaboration environments do we want to address in the federation?

What trade off should we make between complexity of deployment and potential interoperation with other federations?

Do we retrofit LoAs as other federations are now having to do, or do we implement them upfront?

Where do we set the bar (minimum floor of trust)? How should we measure that the IdPs and SPs are at the

appropriate level? What are the guidelines and how will they be measured?

22


Overall Progress to Date Shibboleth:

Test operation (full production but no agreements) since 2006 Schema agreed (?) PKI:

Acquired some of hardware, softwareSome testing undertakenWebTrust Audit later this year

Operational arrangements – proposals drafted Governance, Management, Financial, Legal status still “in discussion”,

but some principles clear:Owned by the sectorFinanced by the sectorSimple legal arrangements: Truth is ever to be found in the simplicity,

and not in the multiplicity and confusion of things – Sir Isaac Newton.

23


Thank You.Questions?

[email protected]

www.aaf.edu.au

www.federation.org.au/FedManager/jsp/index.jsp

www.aaf.edu.au/attributes

www.aaf.edu.au/aaf-federated-access-management-animation

alex reid, aarnet australian access federation; 21-may-08 the australian access federation terena...

Documents