PKI Architecture for VISIONng Proposal by A-TrustA

Transcription

1 PKI Architecture for VISIONng Proposal by A-TrustA October 2001 Stephan Grill

2 Overview Objective Products and Services of A-Trust Requirements Description of the PKI Architecture Certificates Processes Certificate Policy Next Steps

3 Objective This presentation describes the integration of a PKI proposed by A-Trust to support the VoIP pilot of the VISIONng working group The proposal aims to provide a fairly simple solution for the pilot phase which can be generalized for the production phase The proposal is intended as a basis for discussion The proposal is based on limited information gathered in a 2-hour meeting on 2001/10/11

4 A-Trust Products trust sign : Qualified certificate compliant with the Austrian signature law (SigG) and ordinance (SigVO), and the European directive for signatures (article 5 (1)). trust mark token : Certificate based on secure technological components. Compliant with the european directive (article 5 (2)). rust mark vsc : rust mark webserver : rust mark s-box : rust mark developer : rust mark VoIP : rust mark attributes : User certificate based on virtual smart cards Webserver certificate Certificate for an HSM Developer certificate Certificate for the use of VoIP clients Attribute certificate rust client : End user software for the use of certificates and the signatures

5 A-Trust Services egistration Service: evocation Service: irectory Service: CSP Service : A Housing: Service for identifying users that request a certificate Service for subscribes to suspend or revoke a certificate Service to locate certificates and CRLs Service to query a certificate status online Service to manage a CA for other organizations

6 Requirements Ease of Use VoIP telephony should be as easy and comfortable as current telephony technology Central Point of Contact The VoIP operator should be the central point of contact for the customer: Acts as registration authority on behalf of the Trust Service Providers (TSP) Performs billing for the certificates

7 Security Requirements (1) Signaling Connections AD-BES Gatekeeper AD-BES Gatekeeper VoIP Client VoIP provider 1 VoIP Client VoIP provider 2 Secure connections in phase 1 Secure connections in later phases

8 Security Requirements (2) Secured Processes Secure registration of the VoIP client to the gatekeeper (phase 1) Secure communication between gatekeepers (phase 2) Secure subscription of VoIP services at the provider (phase 2) 2-way Authentication Client should be able to verify the identity of the gatekeeper (GK) GK must verify the identiy of the VoIP client Confidential Communication Communication must be confidential Media stream between VoIP clients is not secured using the PKI

9 Security Requirements (3) Relationship between VoIP Provider and TSP All connections within the domain of one VoIP provider are secured by certificates of only one TSP Each VoIP provider selects only one TSP to issue VoIP certificates for its customers Each VoIP domain corresponds exactly to one PKI domain Each VoIP provider may use any TSP as long as the certificates match the policy and format requirements of VISIONng

10 Security Requirements (4) Phase 1 Only connections within a domain are secured Only one root-certificate needs to be managed by the software Phase 2 Connections between different domains are secured as well Certificates of multiple TSPs need to be managed by the software

11 Proposed Architecture Two User Certificates VoIP certificate that supports ease of use (phase 1) E-Commerce certificate that supports high security (phase 2) Server Certificate (phase 1) For authenticating the GK VISIONng root certificate (phase 2) when inter-domain connections must be secured using multiple PKI domains.

12 VoIP Certificate (Phase 1) Supports ease of use - PIN entry is optional Used for registering at the GK Is a soft token certificate Can be moved between different PCs (optional): different PCs at work, home, friend, etc. Information contained in the certificate Same as in trust mark VSC Authentication information for VoIP provider (optional) UPT number

13 E-Commerce Certificate (Phase 2) Supports high security Used for changing subscription information at the provider Can be used for general E-Commerce applications PIN entry is mandatory Smart card certificate (optional) Information contained in the certificate A-Trust proposes the trust mark token certificate

14 Additional Certificates Server Certificate (Phase 1) used for authenticating the GK Information contained in the certificate A-Trust proposes the trust mark webserver certificate VISIONng root certificate (Phase 2) Used to sign the root certificates of individual PKI domains Accepted by all involved VoIP providers and subscribers

15 Description of Processes Client Subscription 1) User contacts VoIP provider to subscribe for VoIP services 2) VoIP provider Collects VoIP subscription information Acts as Registration Authority for the TSP Verifies required identity information for the VoIP certificate Requests keys and certificate from the TSP Updates required user information in the AD-BES Mails pkcs12 file with VoIP keys and certificate to user 3) User downloads/installs the VoIP client software + trust client root certificate already pre-installed 4) User installs VoIP certificate Process needs to be refined depending on: whether user does already have an E-Commerce certificate VoIP provider wants to act as Registration Authority

16 Description of Processes Certificates for Gatekeeper 1) GK generates a key pair 2) GK operator submits a server certificate request to TSP 3) TSP returns the certificate 4) GK operator installs the certificate

17 Description of Processes Certificate Lifetime VoIP Certificate The VoIP operator revokes the certificate when the user cancels the subscription The VoIP operator renews the certificate when the certificate expires before the subscription The user revokes the certificate when misuse of the private key is assumed E-Commerce Certificate Comparable with any other personal identiy certificate

18 Description of Processes Certificate Status Checking VoIP clients and GKs must check the status of certificates This can be done using CRLs or OCSP A-Trust currently provides both services

19 Certificate Policy VoIP Certificate A dedicated policy has to be defined VoIP certificates may only be used for VoIP applications Gatekeeper Certificate A dedicated policy has to be defined

20 Open Questions Relationship between VoIP provider and TSPs Does a VoIP provider work exclusively with only one TSP, i.e. All VoIP certificates of one VoIP provider are issued by the same TSP? Do all VoIP provider act as registration authority of a TSP? Relationship between VoIP vendors and subscribers Subscriber authenticate always to GKs of their VoIP providers; GKs service only requests of their subscribers The list of trusted root certificates does not change Relationship between different VoIP providers Is the VoIP certificate bound uniquely to a VoIP provider? Then it cannot be used for the services of a different VoIP provider. Moving VoIP certificates How should the VoIP certificates be moved to different VoIP clients (just the PKCS12 file, including the trusted root certificate, as part of a comprehensive user profile,...?)

21 Next Steps Refine proposed architecture Overall processes PKI related SW architecture for VoIP client & Gatekeeper Develop specifications related to VoIP certificates Certificate format Registration/revocation process Certificate policy Technical integration of certificates Investigation of the integration of existing VoIP products with A-Trust standard certificates