New Security Services Based on PKI

1. New Security Services Based on PKI Antonio F. Gómez Skarmeta <skarmeta@dif.um.es> University of Murcia SPAIN

2. Agenda • Introduction • The UMU IPv6 PKI (UMU-PKIv6) • Distributed Security Policy Management architecture (DSPM) • Distributed Credential Management System (DCMS) • Conclusions

3. Introduction • PKIs ... key element for providing security to distributed and dynamic networks and services • Our experience ... based on our own designs and implementations: • An IPv6 PKI (UMU-PKIv6) • Two innovative secure distributed services built over this PKI • Distributed Security Policy Management architecture (DSPM) • Based on the concept of policy (set of rules governing choices in the behaviour of one system) • Modifying a policy we can change the behaviour of one system • It defines a new network paradigm, based on flexible and programmable networks • Distributed Credential Management System (DCMS) • Difference between the concepts of certificate and identity certificate • Based on SPKI/SDSI infrastructure • More suitable for complex and distributed environments

4. The UMU IPv6 PKI (UMU-PKIv6)

5. UMU-PKIv6 Description • Main Objective ... to establish a high security infrastructure for distributed systems • Main Features: • First PKI supporting the IPv6 protocol • Developed in Java  running on every Operating System • Issue, renew and revoke certificates for every entity belonging to one organisation • Final users can use either RAs or Web browsers to make their own certification operations • LDAPv6 directory support • Use of smart cards (file system, RSA or Java Cards) ... allowing user mobility and increasing security • PKI Certification Policy support • VPN devices certification support (using the SCEP protocol) • Support for the OCSP protocol and Time Stamp • Web administration

6. VPN Device VPN Device LDAP LDAP LDAP End End End User User User Server Server Server Administrator Administrator Administrator Certification Certification Certification WWW Secure WWW Secure Authority Authority Authority Request Server Request Server Registration Registration Registration Registration Authority Authority Authority Authority IPv6 Plain connection IPv6 SSL connection SCEP SCEP SCEP over IPv6 Data Base Data Base Data Base https://pki.ipv6.um.es UMU-PKIv6 Architecture

7. Distributed Security Policy Management architecture (DSPM)

8. Security Policies • There is ... • high interest in policy-based networking, but • no complete systems supporting the specification and deployment of these policies • Policies used to manage distributed communication systems ... “IF certain conditions are present, THEN specific actions are taken” • Security is vital  we sign every policy (using X.509 certificates issued by our own PKIv6) • We use policies for managing • The UMU-PKIv6 itself • Secure IPv6 VPNs

9. Security Policies for PKIs • UMU-PKIv6 policies • Drive the way the PKIv6 itself works • Digital implementation of a Certification Practice Statement (CPS) ... they specify which rules must be applied to requested or existing certificates • Digitally signed (integrity and authentication) normally by the CA private key • Centralised creation process driven by the PKI admin • Distributed use by RAs and other PKI components • Categories: • Certification rules • Re-issuance rules • Revocation rules

10. Security Policies for PKIs (II) • Information about a Policy

11. Security Policies for VPNs • IPsec • Receiving widespread deployment for implementing VPN • Typical policy-enabled networking service • But ... • IPsec policy databases are normally manually-configured • Growing number of Internet applications using VPNs • Therefore, a IPsec Policy-Based Network Management system (PBNM) is clearly needed • Our designed and implemented PBNM is divided in two different components: • Policy Definition Process • Policy Recovery Process

12. Security Policies for VPNs (II) • Policy Definition Process • IPsec Policy ... “IF conditions include a type of traffic, IP address, and/orTCP/UDP port, THEN actions should include setting certain level ofauthentication and encryption of traffic” • Provides a common means of specifying IPsec policies • Vendor and platform independent • Defined in XML and mapping, using XML style-sheets, onto every IPsec and IKE (freeware or commercial) implementations • Enables a coordinated control of IP-level security services in every administrative domain • Based on the CIM model (from the IETF/DMTF) ... common data schema for describing management information

13. Security Policies for VPNs (III) • Policy Definition Process Schema

14. Security Policies for VPNs (IV) • Policy Recovery Process • It makes use of two kind of entities • Policy Decision Points (PDPs) • Policy Enforcement Points (PEPs) • and one IETF-defined integrated framework of standards based on COPS (Common Open Policy Service) • Three scenarios are currently defined • COPS IPsec node • Non-COPS IPsec node • With SMTP • Without SMTP

15. Security Policies for VPNs (V) • Policy Recovery Process Schema

16. Distributed Credential Management System (DCMS)

17. DCMS Motivation • Most of those SPKI scenarios are based on delegation • Resource controllers have small ACLs delegating access to some particular public keys (authorities) • Application-dependent approaches try to answer: • How do I encode a certification request? • How do I submit the certification request? • How do the authorities specify and enforce the authorization policies? (i.e. who is able to obtain a particular authorization?) • In complex environments, simple command-line (and off-line) applications do not seem to be the right approach

18. DCMS Motivation (II) • It is necessary to address the problems related to scalability and interoperability. • DCMS (Distributed Credential Management System) • DCMS defines: requests, policies, and entities • DCMS is divided into: • NMS: SPKI ID Certificates • AMS: SPKI Attribute and Authorization Certificates • Entities exchange authorization information using the AMBAR Protocol (similar protocols are valid too) • Main goal of DCMS: to be application-independent

19. DCMS-NMS (Naming Management System) • NMS is responsible for certification operations related to SPKI ID certificates • This type of certificates can be used to: • link a name to a particular public key (principal) • define group membership • NMS can be especially useful when authorization is based on groups of principals • NMS can be used by the principals in order to obtain an ID certificate for group G • ID certificates are issued by naming authorities (NA)

20. DCMS-NMS Entities • Requestors: • They create certification requests • Additional certificates can be also attached to the requests • Two types of requestors: • Demanding an ID certificate for a name (subgroups) • Demanding an ID certificate for a public key

21. DCMS-NMS Entities • Service Access Points (SAP): • Requestors use SAPs to submit the certification requests • Several advantages: • Naming authorities can be protected • They “know” the appropriate naming authorities • Public terminals placed at buildings or departments

22. DCMS-NMS Entities • Naming Authorities (NA): • NAs are controlled by authorization policies • In DCMS, those policies are implemented using SPKI ACLs • Use of certificate chain discovery methods • Input: request, additional certificates, ACL • Output: data used to generate the new certificate

23. (cert (issuer (name NA-pk N)) (subject P) (valid …) ) (tag (cert-request (issuer (name NA-pk N)) (subject P) (valid …) ) ) DCMS-NMS Requests and ACL Entries • NMS s-expressions: • There is no need for a new syntax (we use the certificate struct) • Main differences: • N can be a (* prefix) form or a (* set) form • P can make reference to several principals (* set Q S T) • valid is making reference to the intended validity period • The request is signed by the requestor, not by the issuer

24. DCMS-NMS example (sequence (tag (cert-request (issuer (name morpheus-pk Nebuchadnezzar)) (subject neo-pk) ) ) (signature …) ) • Request and additional certificate (cert (issuer (name morpheus-pk Nebuchadnezzar)) (subject trinity-pk) ) (acl (entry (subject (name morpheus-pk Nebuchadnezzar)) (tag (cert-request (issuer (name morpheus-pk Nebuchadnezzar)) (subject (* set neo-pk trinity-pk switch-pk)) ) ) ) • ACL

25. DCMS-AMS (Authorization Management System) • AMS is responsible for the certification operations related to SPKI Attribute and Authorization certificates • NMS and AMS are based on similar entities: • Requestors and SAPs are also part of AMS • NAs are replaced by AAs (Authorization Authorities) • S-expressions for requests and ACLs are similar to those defined for NMS (including propagation and tags) • There are also two types of requestors: • Requestors of authorization certificates • Requestors of attribute certificates

26. DCMS-AMS Role Managers • We need to encode statements like: • Psion-AA authorizes the Role Manager RM to request attribute certificates granting the set of permissions tag-A for group Nebuchadnezzar defined by Morpheus (acl (entry (subject RM-pk) (tag (cert-request (issuer psion-pk) (subject (name morpheus-pkNebuchadnezzar)) (tag tag-A) ) ) )

27. DCMS Implementation • AMBAR was implemented using Intel CDSA 3.14 • DCMS is being implemented also using CDSA • Graphical User Interface (QT libraries) • Red Hat Linux 7.1 • Several applications: • DCMS tag constructors • ACL Management • Authorities • Service Access Points

28. DCMS Implementation

29. Conclusions

30. Conclusions • UMU-PKIv6 ... provides a common trustworthy point for new distributed services, like: • DSPM that provides: • New active network management paradigm based on policies (for several scenarios: UMU-PKIv6 and VPNs) • Expressed in XML • Based on IETF/DMTF standards: CIM and COPS • DCMS that provides: • Certification requests (s-expressions) • Authorization policies (SPKI ACLs) • Architectural elements

31. New Security Services Based on PKI Antonio F. Gómez Skarmeta <skarmeta@dif.um.es> University of Murcia SPAIN