1 / 9

AAVS

AAVS. Middleware Security Group Bob Cowles CERN – September 14, 2005. Proxy Certificates. Self-signed by an end-entity – not normally acceptable RFC 3820 defines motivation and usage Private key not protected except by file system security No CRL. Compromise Mitigations.

sakina
Download Presentation

AAVS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AAVS Middleware Security Group Bob Cowles CERN – September 14, 2005

  2. Proxy Certificates • Self-signed by an end-entity – not normally acceptable • RFC 3820 defines motivation and usage • Private key not protected except by file system security • No CRL

  3. Compromise Mitigations • Only a single user • Limited lifetime • Does not compromise the original end-entity certificate • Can be restricted in usage

  4. Drawbacks Actual Use • Lifetime may not be very limited • No real agreement on renewal process • Little use of limiting capabilities

  5. Moving Ahead Renewal • Can enforce limited lifetime constraint • If application error, things don’t work and the bug gets fixed • However • Proxy still exposed for inappropriate use until it expires • Significant resources can e consumed that are wasted

  6. Moving Ahead Revocation • Can use OCSP for “lighter weight” and more timely revocation • Allows for more prompt revocation of compromised proxys • However • Application may not be able to get information from server • Increased complexity of certificate validation

  7. Moving Ahead • Path forward is not clear • Will need to use experience • Need to maintain flexibility • Need to increase security of checks from compromise • If we have strong auth structure, do we even care about revoking authentication?

  8. AAVS • AA Validation Service • Start with standard API of library routines for applications to call • Move as quickly as possible to external service • Eases load on application developers • More flexibility as new requirements are discovered

  9. CommentsDiscussion?

More Related