Enhancing Security with Proxy Certificates: Challenges and Future Directions
This document discusses the complexities and limitations of using self-signed proxy certificates as outlined by Bob Cowles from CERN. It highlights issues such as security vulnerabilities due to inadequate key protection and the challenges in lifecycle management and renewal processes. Current use cases reveal a lack of consensus on renewal and restrictive capabilities. Moving forward, the emphasis should be on enacting timely revocation via OCSP, maintaining flexibility, and reinforcing security checks to safeguard against compromises. The role of the AAVS (AA Validation Service) is also examined to ease application development burdens.
Enhancing Security with Proxy Certificates: Challenges and Future Directions
E N D
Presentation Transcript
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 • Only a single user • Limited lifetime • Does not compromise the original end-entity certificate • Can be restricted in usage
Drawbacks Actual Use • Lifetime may not be very limited • No real agreement on renewal process • Little use of limiting capabilities
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
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
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?
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
