4th Annual PKI R&D Workshop: Multiple Paths to Trust April 19-21, 2005, NIST, Gaithersburg MD Online Proceedings The official proceedings are published as a NIST Technical Publication, and available for download: NISTIR 7224. This online version of the proceedings reflects the original program, and includes everything in the official proceedings (papers and summaries) as well as those presentation materials that have been provided by the presenters. The Pre-Proceedings (a 197-page pdf, 113 MB long) are also available. Workshop Summary Ben Chinowsky Internet2: Workshop Summary (HTML) Tuesday, April 19 2005 9:00 - 9:15 Opening Remarks Ken Klingenstein General Chair Clifford Neuman Program Chair 9:15 - 10:45 Session 1: Papers - Shibboleth and more Session Chair: Neal McBurnett Internet2 Adding Distributed Trust Management to Shibboleth: paper (pdf), presentation (pdf) David Chadwick, Sassa Otenko, Wensheng Xu, and Zhi Qing Wu University of Kent, England Attributes, Anonymity, and Access: Shibboleth and Globus Integration to Facilitate Grid Collaboration: paper (pdf), presentation (ppt) Von Welch, National Center for Supercomputing Applications, University of Illinois, Tom Barton, Networking Services & Information Technologies, University of Chicago, Kate Keahey, Argonne National Laboratory, and Frank Siebenlist, Argonne National Laboratory XPOLA - An Extensible Capability-based Authorization Infrastructure for Grids paper (pdf), presentation (ppt) Liang Fang, Indiana University, Dennis Gannon, Indiana University, and Frank Siebenlist, Argonne National Laboratory 11:15 - 12:45 Session 2 - Panel - PKI Interoperability and Federations Session Chair: Peter Alterman National Institutes of Health Interfederation Interoperability, E-Authentication and Shibboleth Ken Klingenstein University of Colorado; Internet2: presentation (pdf) International and Bridge-to-Bridge Interoperability Peter Alterman National Institutes of Health: presentation (pdf) HEBCA and Phase 4 of the PKI Interoperability Project: presentation (ppt) Scott Rea Dartmouth College 2:00 - 3:30 Session 3 Papers: Services in Support of PKI Session Chair: Von Welch National Center for Supercomputing Applications, University of Illinois The Design and Implementation of LDAP Component Matching for Flexible and Secure Certificate Access in PKI: paper (pdf), presentation (ppt) Sang Seok Lim, IBM T.J. Watson Research Center, Jong Hyuk Choi, IBM T.J. Watson Research Center, and Kurt D. Zeilenga, IBM Linux Technology Center PKI without Revocation Checking: paper (pdf) Karl Scheibelhofer, Institute for Applied Information Processing and Communications, Graz University of Technology Delegation Issuing Service for X.509: paper (pdf), presentation (pdf) David W. Chadwick, IS Institute, University of Salford, Salford, England 3:45 - 5:15 Session 4: Papers - PKI In government Session Chair: Olga Kornievskaia University of Michigan Meeting the Challenges of Canada's Secure Delivery of E-Government Services: paper (pdf), presentation (ppt) Mike Just and Danielle Rosmarin, Public Works and Government Services Canada The Use of PKCS-12 in the Federal Government: paper (pdf) Tice F. DeYoung, National Aeronautics Space Administration Secure Access Control with Government Contactless Cards: paper (pdf), presentation (ppt) David Engberg, CoreStreet, Ltd. Wednesday, April 20 2005 9:00 - 10:00 Invited Talk Progress in Hashing Cryptanalysis: presentation (ppt) Arjen Lenstra Bell Labs (Lucent Technologies) 10:30 - 11:30 Session 5: Papers - Improving the Usability of PKI Session Chair: Eric Norman University of Wisconsin Identity-Based Encryption with Conventional Public-Key Infrastructure: paper (pdf), presentation (pdf) Jon Callas, PGP Corporation A Proxy-Based Approach to Take Cryptography Out of the Browsers for Better Security and Usability: paper (pdf), presentation (ppt) Marco Carnut, Tempest Security Technologies and Evandro Curvelo Hora, Universidade Federal de Sergipe - DCCE/CCET 11:30 - 1:00 Session 6: Standards Activities Session Chair: Clifford Neuman USC-ISI Internet Engineering Task Force update Russ Housley Vigil Security LLC and Tim Polk NIST Pairing standards for Identity Based Encryption: presentation (ppt) Terence Spiess Voltage Security 2:00 - 3:30 Session 7: Papers - Scale and performance Session Chair: Carl Ellison Microsoft Side-Effects of Cross-Certification: paper (pdf), presentation (ppt) James Fisher, Mitretek Systems Evaluating the Performance Impact of PKI on BGP Security: paper (pdf), presentation (pdf) Meiyuan Zhao, Dartmouth College, Sean Smith, Dartmouth College, and David Nicol, University of Illinois at Urbana-Champaign Observations from the Deployment of a Large Scale PKI: paper (pdf), presentation (ppt) Rebecca Nielsen, Booz Allen Hamilton 4:00 - 5:30 Session 8: Work-in-Progress talks Ceremony Analysis: presentation (ppt) Carl Ellison Microsoft An idea for Instantaneous Secure Enrollment: presentation (ppt) Marco Carnut, Tempest Security Technologies Modeling Strength of Security & Its application in PKI: ppresentation (ppt) Ho Chung, University of Southern California and Clifford Neuman, USC-ISI PKI Projects in Brazil Jeroen Van de Graaf, Universidade Federal de Minas Gerais 8:00 - 9:00 Birds of a Feather session Usability and Human Factors Eric Norman University of Wisconsin Thursday, April 21 2005 9:00 - 10:00 Session 9: Miscellaneous Session Chair: Kent Seamons Brigham Young University Language Based Policy Analysis in a SPKI Trust Management System: paper (pdf), presentation (ppt) Arun K. Eamani and A. Prasad Sistla, University of Illinois at Chicago Enhancing Security of Security-Mediated PKI by One-time ID: paper (pdf) Satoshi Koga, Kenji Imamoto, and Kouichi Sakurai, Kyushu University, Japan 10:30 - 12:30 Session 10 Paper and Panel - PKI In Healthcare Session Chair: Rich Guida Johnson & Johnson On Securing the Public Health Information Network Messaging System: paper (pdf), presentation (ppt) M. Barry Rhodes, Centers for Disease Control and Prevention and Rajashekar Kailar, Business Networks International Inc. PANEL: PKI In Healthcare Richard Guida Johnson & Johnson presentation (ppt), Terry Zagar Biopharma SAFE initiative: presentation (ppt), John Landwehr Adobe: presentation (pdf), See Also •2006: 5th Annual PKI R&D Workshop •2005: 4th Annual PKI R&D Workshop •2003: 2nd Annual PKI Research Workshop •2002: 1st Annual PKI Research Workshop 4th Annual PKI R&D Workshop: Multiple Paths to Trust Pre-Proceedings April 19-21, 2005 Gaithersburg, Maryland USA 4th Annual PKI R&D Workshop Pre-Proceedings ii 4th Annual PKI R&D Workshop Pre-Proceedings 4th Annual PKI R&D Workshop: Multiple Paths to Trust General Chair: Ken Klingenstein, Internet2 Program Chair: Clifford Neuman, University of Southern California Steering Committee Chair: Neal McBurnett, Internet2 Local Arrangements Chair: Nelson Hastings, NIST Scribe: Ben Chinowsky, Internet2 Proceedings: Sara Caswell, NIST Program Committee Clifford Neuman, USC-ISI (chair) John Mitchell, Stanford University Peter Alterman, NIH Eric Norman, University of Wisconsin Bill Burr, NIST Tim Polk, NIST Yassir Elley, Sun Microsystems Ravi Sandhu, George Mason University; NSD Security Carl Ellison, Microsoft Krishna Sankar, Cisco Systems Stephen Farrell, Trinity College Dublin Jeff Schiller, MIT Richard Guida, Johnson & Johnson Kent Seamons, Brigham Young University Steve Hanna, Sun Microsystems Frank Siebenlist, Argonne National Lab Peter Honeyman, University of Michigan Sean Smith, Dartmouth College Russ Housley, Vigil Security LLC Michael Wiener, Cryptographic Clarity Ken Klingenstein, Internet2 Von Welch, NCSA Olga Kornievskaia, University of Michigan Will Winsborough, George Mason University Neal McBurnett, Internet2 Archival Sites PKI 2005: http://middleware.internet2.edu/pki05 PKI 2004: http://middleware.internet2.edu/pki04 PKI 2003: http://middleware.internet2.edu/pki03 PKI 2002: http://www.cs.dartmouth.edu/~pki02 iii 4th Annual PKI R&D Workshop Pre-Proceedings iv 4th Annual PKI R&D Workshop Pre-Proceedings 4th Annual PKI R&D Workshop: Multiple Paths to Trust Gaithersburg, Maryland USA April 19-21, 2005 http://middleware.internet2.edu/pki05/ REFEREED PAPERS Adding Distributed Trust Management to Shibboleth 3 David Chadwick University of Kent, England Sasso Otenko University of Kent, England Wensheng Xu University of Kent, England Attributes, Anonymity, and Access: Shibboleth and Globus Integration to Facilitate Grid Collaboration 15 Von Welch NCSA, University of Illinois Tom Barton NSIT, University of Chicago Kate Keahey Argonne National Laboratory Frank Siebenlist Argonne National Laboratory XPOLA – An Extensible Capability-based Authorization Infrastructure for Grids 26 Liang Fang Indiana University Dennis Gannon Indiana University Design and Implementation of LDAP Component Matching for Flexible and Secure Certificate Access in PKI 37 Sang Seok Lim IBM Watson Research Center Jong Hyuk Choi IBM Watson Research Center Kurt D. Zeilenga IBM Linux Technology Center PKI without Revocation Checking 48 Karl Scheibelhofer Institute for Applied Information Processing and Communications, Graz University of Technology Delegation Issuing Service for X.509 62 David Chadwick University of Kent, England Meeting the Challenges of Canada’s Secure Delivery of E-Government Services 74 Mike Just Public Works & Govt Services Canada Danielle Rosmarin Public Works & Govt Services Canada The Use of PKCS-12 in the Federal Government 85 Tice F. DeYoung National Aeronautics and Space Administration Secure Access Control with Government Contactless Cards 89 David Engberg CoreStreet, Ltd. v 4th Annual PKI R&D Workshop Pre-Proceedings Identity-Based Encryption with Conventional Public-Key Infrastructure 98 Jon Callas PGP Corporation A Proxy-Based Approach to Take Cryptography Out of the Browsers for 112 Better Security and Usability Marco Carnut Tempest Security Technologies Evandro Hora Universidade Federal de Sergipe - DCCE/CCET Side-Effects of Cross-Certification 130 James Fisher Mitretek Systems Evaluating the Performance Impact of PKI on BGP Security 140 Meiyuan Zhao Dartmouth College Sean Smith Dartmouth College David Nicol University of Illinois-Urbana Champaign Observations from the Deployment of a Large Scale PKI 155 Rebecca Nielsen Booz Allen Hamilton Language Based Policy Analysis in a SPKI Trust Management System 162 Arun K. Eamani University of Illinois at Chicago A. Prasad Sistla University of Illinois at Chicago Enhancing Security of Security-Mediated PKI by One-time ID 176 Satoshi Koga Kyushu University Kenji Imamoto Kyushu University Kouichi Sakurai Kyushu University On Securing the Public Health Information Network Messaging System 190 Barry Rhodes Centers for Disease Control & Prevention Rajashekar Kailar Business Networks International, Inc. vi 4th Annual PKI R&D Workshop Pre-Proceedings REFEREED PAPERS 1 4th Annual PKI R&D Workshop Pre-Proceedings 2 4th Annual PKI R&D Workshop Pre-Proceedings Adding Distributed Trust Management to Shibboleth David Chadwick, Sassa Otenko, Wensheng Xu University of Kent, Computing Laboratory, Canterbury, England, CT2 7NF each Shibboleth target resource site trusts Abstract each Shibboleth origin (home) site in the This paper analyses the simplicity of the federation, so that whatever assertions – trust model adopted by the Shibboleth authentication or authorisation – are infrastructure and describes an enhanced digitally signed by the origin site, they will distributed trust model and authorisation be believed and trusted by the target site. decision making capability that can be There is little scope for differentiation implemented by using X.509 attribute between authentication authorities and certificates and a Privilege Management attribute authorities, or for allowing more Infrastructure such as PERMIS. Several sophisticated distribution of trust, such as different combinatorial approaches can be static or dynamic delegation of authority. taken, depending upon the trust models adopted by the Shibboleth target and origin Another limitation of the Shibboleth sites, and each of these are described. The infrastructure is that it only provides a basic paper also discusses whether user privacy, access control decision making capability. which is strongly protected by Shibboleth, is Whilst this is adequate for many use cases, it bound to be weakened by the use of X.509 lacks the flexibility and sophistication attribute certificates rather than simple needed by many applications, for example, attributes, and concludes that this does not to make access control decisions based on have to be the case. role hierarchies or various constraints such as the time of day or separation of duties. 1. Introduction We realised that both these limitations could Shibboleth [1] is a distributed web resource be addressed by integrating an X.509 access control system that allows federations Attribute Certificate (AC) Privilege to co-operate together to share web based Management Infrastructure (PMI) [3] with resources. It has done this by defining a Shibboleth. PERMIS [2] is one such protocol for carrying authentication infrastructure that has already been information and user attributes from a home successfully integrated into Grid application site to a resource site. The resource site can target sites [4] to support the distributed then use the attributes to make access management of trust. PERMIS incorporates control decisions about the user. The a sophisticated policy controlled RBAC Shibboleth project is run by the Internet2 access control decision engine (also called a consortium in the USA, and universities policy decision point (PDP)). The PERMIS throughout the USA and Europe (at least) PMI has been used to implement distributed are now starting to build experimental trust management in Shibboleth. services based upon it. The rest of this paper is structured as At the heart of Shibboleth is a trust model follows. Section 2 provides an overview of that allows the members of a federation to Shibboleth. Section 3 introduces the more cooperate together. This trust model, whilst sophisticated distributed trust model that we functional, is somewhat limited. Basically 3 4th Annual PKI R&D Workshop Pre-Proceedings wanted to introduce into Shibboleth. Section authenticate its users properly. This is 4 describes how the trust model can be facilitated by the exchange of public key implemented using an X.509 PMI such as certificates or the use of a common trusted PERMIS. Section 5 describes the different root Certification Authority. In the latter combinations of X.509 ACs, attributes, and case both sites will have been issued with a the PERMIS PDP that may be integrated certificate by the root CA (or one of its with Shibboleth to provide the desired trust subordinates). When a digitally signed models of the Shibboleth target and origin SAML message1 arrives from the home site, sites. Section 6 discusses user privacy such as one containing a user handle, this issues and section 7 discusses revocation can be validated and trusted by the resource and performance issues that arise with using site. X.509 ACs. Finally Section 8 concludes. After the user has picked his/her home site, 2. Overview of Shibboleth their browser is redirected to their site’s Shibboleth is a web based middleware layer authentication server and the user is invited that currently makes use of SAMLv1.1 [5] to log in. If a user is untrustworthy and tries for encoding some of its messages. When a to fool the system by picking a home site to user contacts a Shibboleth resource site from which they do not belong, they will have their browser, requesting access to a difficulty authenticating themselves to that particular URL, Shibboleth single sign on site’s authentication server, since they won’t and access control takes place in two stages: have any valid credentials. However, if they – In stage one the resource site pick their own home site, they should find redirects the user to their home site, authentication is no problem. After and obtains a handle for the user that successful authentication, the home site re- is authenticated by the home site directs the user back to the resource site and – In stage two, the resource site returns the message carries a digitally signed SAML the handle to the attribute authority authentication assertion message from the of the home site and is returned a set home site, asserting that the user has been of attributes of the user, upon which successfully authenticated by a particular to make an access control decision. means e.g. username/password, Kerberos or In a large distributed open environment digital signature. The actual mechanism stage one has a number of complications. used is local to the home site, and the Firstly how does the resource site know resource site simply has to have a prior where the user’s home site is? Secondly, agreement with the home site which how can the resource site trust the handle authentication mechanism(s) will be trusted. that is returned? The answer to these two If the digital signature on the SAML questions is surprisingly simple, and is part of the Shibboleth trust model. When the user 1 Note that the connection from the origin server to first attempts to access a resource site, the target server can also be optionally protected by he/she is redirected to a Where Are You SSL in Shibboleth, but this is used to provide From? (WAYF) server, that simply asks the confidentiality of the connection rather than message user to pick his/her home site from a list of origin authentication. In many cases a confidential SSL connection between the origin and the target will known and trusted home (Shibboleth origin) not be required, since the handle is obscure enough to sites. The target site already has a pre- stop an intruder from finding anything out about the established trust relationship with each user, whilst the SAML signature makes the message home site, and trusts the home site to exchange authentic. 4 4th Annual PKI R&D Workshop Pre-Proceedings authentication assertion verifies OK, then have some say over the contents of their the resource site has a trusted message attribute release policies. This is to minimise providing it with a temporary pseudonym the loss of a user’s privacy. for the user (the handle), the location of the attribute authority at the origin site and the 3. An Enhanced Trust Model for resource URL that the user was previously Shibboleth trying to access. The resource site then As can be seen from the above overview of returns the handle to the home site’s Shibboleth, its trust model is sound although attribute authority in a SAML attribute rather limited. The model is that the target query message and is returned a signed site trusts the origin site to authenticate its SAML attribute assertion message. The users and to manage their attributes correctly Shibboleth trust model is that the target site whilst the origin site trusts the target site to trusts the origin site to manage each user’s provide services to its users. The trust is attributes correctly, in whatever way it conveyed using digitally signed SAML wishes. So the returned SAML attribute messages using target and origin server assertion message, digitally signed by the X.509 key pairs/certificates, configured into origin, provides proof to the target that the the Shibboleth software by their filenames. authenticated user does have these attributes. (Note that the private key files were held This message exchange should be protected unencrypted in the Shibboleth software we by SSL if confidentiality/privacy of the were using, so this is a weakness in the returned attributes is required. The attributes implementation if not actually in the trust in this assertion may then be used to model.) As each site will typically only have authorise the user to access particular areas one key pair per Shibboleth system, from of the resource site, without the resource site the recipient’s perspective, there is only a ever being told the user’s identity. single point of trust per sending Shibboleth system. Although it is not difficult to The latest version of the Shibboleth configure multiple roots of trust into a specification has introduced a performance Shibboleth target site – it is, in fact, a matter improvement over the earlier versions, by of updating one XML file only – the issue is optionally allowing stage one and stage two one of being able to use a finer grained to be combined together, in that the initial distributed trust model, and of being able to digitally signed SAML message may use multiple origin site authorities (and optionally contain the user’s attributes as private keys) to issue and sign the well as the authentication assertion. It is authentication and attribute assertions. expected that the Shibboleth software will be upgraded to this during 2005. In many origin sites a single back end LDAP server is the sole authoritative source Shibboleth has two mechanisms to ensure for both authentication and attribute user privacy. Firstly it allows a different information. Typically Shibboleth sites pseudonym for the user’s identity (the implement stage one by issuing a Bind handle) to be returned each time, and operation on their LDAP server, using the secondly it requires that the attribute username and password provided by the user authorities provide some form of control to the web login prompt. If the Bind over the release of user attributes to resource succeeds, the user has been successfully sites, which they term an attribute release authenticated against the password stored in policy. Both users and administrators should the LDAP server. Stage two is implemented 5 4th Annual PKI R&D Workshop Pre-Proceedings by searching the LDAP server for the project leader attribute to an employee attributes stored in the user’s entry, and under his control. filtering these against the Shibboleth - The target should be able to state, in its origin’s attribute release policy before policy, which of the attribute authorities returning them to the Shibboleth target site it trusts to issue which attributes to as signed SAML attribute assertions. One which groups of users. The target site can see that in such an implementation, and should be able to decide independently as a consequence of the Shibboleth trust of the issuing site which attributes and model, the Shibboleth target site has no authorities to trust when making its choice but to make access control decisions access control decisions. based on these attributes, without knowing - Not all attribute issuing authorities need who actually issued them to the user, be part of the origin site. A target site whether they are still valid or not, or should be able to allow a user to gain whether they are even the correct attributes access to its resources if it has attributes for the particular user, since the user’s name issued by multiple authorities, for is not provided to the target site for privacy example, a target site holding statistics reasons. The Shibboleth origin doesn’t trust on medical data may require a user to anyone to see the attributes except the have an attribute issued by a medical trusted targets, but even they are not allowed authority as well as one issued by the to see the binding between the attributes and university that employs the user as a the owner’s identity. (The two reasons given researcher. for this in the Shibboleth documentation are - The trust infrastructure should support user privacy and legal requirements for dynamic delegation of authority, so that universities to protect a student’s privacy). a holder of a privilege attribute may The target site thus has no option but to delegate (a subset of) this to another indirectly trust the contents of the origin person without having to reconfigure site’s LDAP server or other attribute anything in the system. For example, a repository, since it trusts the origin site project leader may wish to assign a role directly. One can further see that the origin of team leader to one of his team site has to strongly protect the attributes in members; he should be enabled to do its (LDAP) repository, which means that it is this dynamically by the infrastructure probably restricted to centrally without having to reconfigure the administering these, and so would prefer system. The target site should be able, in that they do not change that often. turn, to state in its policy whether it Flexibility and distributed management of trusts these delegated attributes or not, the attributes is hard to adopt. Dynamic regardless of the delegation policy at the delegation of authority would be even harder user’s site. to support. - The target site should be able to decide if it really does trust the origin’s attribute We propose that an enhanced trust model repository (e.g. LDAP server), and if should have the following features. not, be able to demand a stronger proof - Multiple authorities should be able to of attribute entitlement than that issue attributes to the users, and the conferred by a SAML signature from the target site should be able to verify the sending Web server. issuer/user bindings. For example, a - Finally, the origin site, if it chooses, manager should be able to assign a should be able to use a Privilege 6 4th Annual PKI R&D Workshop Pre-Proceedings Management Infrastructure, rather than a repository or the underlying transport strongly protected attribute repository, mechanism used to convey them, since it for allocating attributes to its users. This can directly validate the digital signatures on will allow the origin to distribute the the attribute certificates when it receives management of attributes throughout its them2. Furthermore, if the target site’s PDP site. Nevertheless, the origin site should policy is willing to allow dynamic still be able to communicate with delegation of authority, the PDP can check Shibboleth targets as usual by only the attribute certificate chain to ensure that sending attributes to them, if the targets all ACs were properly authorised by their are happy to trust these. issuing authorities. By using ACs in its authorisation decision making, rather than 4. Implementing the Enhanced plain attributes, a target site can support Trust Model using an X.509 PMI much more sophisticated and finer grained X.509 attribute certificates (ACs) provide a access control policies, for example, by convenient, standardised and compact requiring a user to have ACs issued by representation of attribute assignments, and multiple authorities, from different issuing satisfy several of the above requirements. domains, before they are granted access to The basic X.509 attribute certificate particular resources. construct comprises: the name of the holder of the attributes, the name of the issuing The PERMIS X.509 PMI is part of the US authority, the set of attributes, and the time NSF Middleware Initiative software release. that they are valid for. An extension field PERMIS provides a policy controlled role can optionally be inserted to state that the based access control (RBAC) infrastructure, holder is allowed to dynamically delegate (a in which the user’s roles are stored in X.509 subset of) these attributes to another user, ACs. These ACs are either passed to the and the depth to which delegation can take PERMIS PDP along with the user’s place. The whole AC construct is digitally requested action (the push model), or can be signed by the issuer (attribute authority), fetched from one or more LDAP servers by thus providing integrity control and tamper the PDP (the pull model). The PERMIS resistance. Multiple attribute authorities can PDP then returns a granted or denied co-exist, either in a hierarchical relationship response according to the policy in force at or as separate independent authorities. that time. The PERMIS policy is written in Attribute certificates are typically long lived, XML, and is in many respects a simplified and after issuance, the ACs need to be stored alternative to XACML [6], although the somewhere for retrieval by the target’s PERMIS policy supports dynamic policy decision point (PDP), and LDAP delegation of authority, unlike XACML. repositories at the AA site are a natural The XML policy is itself stored in an X.509 choice for this, although web servers, attribute certificate, and is digitally signed filestores and other repositories can also be by the trusted authority in control of a target used. resource. This policy certificate is the root of 2 It is the case with ACs that the holder’s identity is If the ACs are stored in the AA site’s LDAP revealed in the Holder field of the AC. But the directory or other repository, and transferred Holder field could still be an opaque string, from there to the target site’s PDP by understood by the Issuer at the Origin, and it doesn’t Shibboleth, then the target site’s PDP does have to be understood by the AC verifier at the not need to indirectly trust the attribute Target site. See section 6 for a fuller discussion of this issue. 7 4th Annual PKI R&D Workshop Pre-Proceedings trust for the access control decision making. current roles/attributes is allowed to access a When the PERMIS PDP is initialised, it is particular target resource, it consults the given the name of the trusted authority, and TAP and returns granted or denied based on the ID of the policy to use (each policy has a its contents and the current state of the globally unique identifier). PERMIS reads in environment (time of day, resource usage the policy certificates from the authority’s etc.). LDAP entry, checks their signatures, and keeps the one with the correct ID. It now has Because PERMIS can act in either push or the correct trusted policy with which to pull mode with attribute certificates, then it make access control decisions. PERMIS is possible for a target site to create a policy thus forms a good basis for demonstrating that requires a user to have attributes issued the distributed management of trust with by multiple different authorities in different Shibboleth. domains, and the PERMIS PDP can then pull these at authorisation time regardless of 4.1 The PERMIS PDP Policy the origin site that the user has actually The PERMIS policy contains a list of trusted authenticated to. attribute authorities, the set of attributes they are trusted to assign, and the groups of users 5. Supporting the different trust they can be assigned to. This is called the models of Shibboleth sites role allocation sub-policy (RAP). Attribute One can immediately see that if Shibboleth authorities can be distributed worldwide, and PERMIS are integrated together, then and can be trusted to issue ACs to users the enhanced distributed trust model that we from any domain, according to the RAP. wish to provide to target and origin sites can When the PERMIS PDP is passed a set of be obtained. However, a number of attribute certificates by Shibboleth, it can misalignments between PERMIS and determine from the RAP which are trusted Shibboleth need to be addressed first. Either to keep, and which should be discarded as Shibboleth needs to transfer X.509 attribute untrusted. All the trusted attributes are certificates (ACs) from the origin site to the extracted and stored for later access control resource site instead of plain attributes, or decision making. PERMIS needs to be modified to accept plain attributes instead of X.509 ACs. In The PERMIS policy also contains the set of fact, both of these methods have been targets that are being protected by this implemented so as to provide resource sites policy, the associated actions that can be with the maximum of flexibility. We have performed on them (along with their modified the Shibboleth origin site to parameters), and the attributes (or roles) that retrieve X.509 ACs from its LDAP a user needs in order to be granted the directory, and to pass these as text encoded access. In addition, constraints can be placed binary attributes within the SAML attribute on these grants, such as, only between 9am assertions. This facility should be provided and 5pm, or only if the user holds non- as part of the standard Shibboleth software conflicting roles3, or only if the size is less release during 2005. We have also modified than 3Mbytes etc. This is called the target the code that calls the PERMIS PDP to access sub-policy (TAP). When the validate the plain attributes from Shibboleth PERMIS PDP is asked if a user with the and use these instead of or as well as X.509 3 ACs. Separation of duties is currently being implemented but is not in the current NMI release. 8 4th Annual PKI R&D Workshop Pre-Proceedings Since it is the target site’s resources that are business lounge may be granted by being accessed, we are primarily concerned presenting frequent flyer cards from a with the trust that a target site is expected or number of different airlines or diners clubs.) required to have in the attributes that it On the other hand, if the target site is not receives in order for it to become Shibboleth willing to recognise these multiple enabled. An origin site will also have its authorities, then the origin site will need to own preferred trust model for the allocation (re-)sign all the SAML attribute assertions of attributes, but the target site’s trust model by the single authority that the target site is must always take precedence since it is the willing to trust. owner of the resources that are being accessed. We can look at trust from two Secondly, we consider the origin site’s different aspects: the distribution of trust in attribute repository (typically an LDAP the attribute issuing authorities (centralised server). If either the target or origin site do or distributed) and the trustworthiness of an not trust this to store unprotected attributes origin site’s attribute repository (trusted or securely, then the origin will need to store not). digitally signed attributes in it, rather than plain attributes. We now consider each Firstly, we consider the distribution of trust. combination in turn. Figure 1 pictorially In the simplest case the origin site has a represents each of the trust models shown in single attribute issuing authority. If the the following sections. target site trusts the origin site’s attribute authority, this authority can issue and sign 5.1 Target trusts origin’s attribute all the SAML attribute assertions. (This is repository and origin as a single the standard Shibboleth model.) attribute authority Alternatively, the origin site may wish to This is the original Shibboleth trust model distribute the management of attributes and both the target site and origin site will between different trusted authorities in its use standard Shibboleth. The origin will domain and to allow dynamic delegation of store plain attributes in its repository, and authority. If the target site wishes to pass them in digitally signed SAML distribute its trust to these different messages to the target. The target site may authorities, then it can allow (trust) each one use the standard Shibboleth authorisation of them to issue and sign different attribute mechanism, or optionally, for a finer grained assertions, and further decide if it will allow and more refined access control mechanism, dynamic delegation of authority to take use a policy controlled PDP to make place. Furthermore, in this distributed trust decisions. When using the PERMIS PDP for scenario, the target site may be willing to authorisation, the PERMIS target access trust, or even require, some attribute sub-policy (TAP) is used to say which authorities that are not even based at the attributes are needed in order to gain access origin site to issue attributes to users. (This to the targets, and the (unsigned) attributes is typically the case in today’s world when from the SAML message are passed to the one presents plastic cards from multiple PERMIS PDP. different issuers in order to gain access to a particular resource e.g. access to an airport 9 4th Annual PKI R&D Workshop Pre-Proceedings Shibboleth Shibboleth Origin Target Shibboleth Shibboleth Domain Transfer attributes Domain Origin Target Domain Transfer ACs Domain TAP 5.1 Standard Shibboleth RAP/TAP 5.2 Multiple ACs at Origin Shibboleth Origin Domain Transfer DN Shibboleth Target Domain X Shibboleth Shibboleth Origin Target RAP/TAP Domain Transfer ACs Domain RAP/TAP 5.3 Pull ACs from multiple AAs 5.4 Untrustworthy attribute repository RAP= role assignment policy Shibboleth Shibboleth TAP=target access policy Origin Target Domain Transfer attributes Domain = attribute repository RAP TAP = AA 5.5 Multiple AAs at Origin not trusted by Target Figure1. Pictorial representation of different trust models this. Additionally, the target may allow 5.2 Origin wishes to distribute dynamic delegation of authority at the origin attribute assignments and target site, by specifying this in the RAP4. trusts different attribute Shibboleth now fetches attribute certificates authorities at the origin from the origin site, rather than plain In this scenario the origin distributes attributes. Consequently the SAML attribute management between multiple authorities assertions do no need to be signed, though and therefore must store attribute certificates the link will still need to be SSL encrypted if in its repository, so that the different privacy protection is required. In this attribute authorities can be recognised by the scenario the origin’s attribute repository target. The target site uses the role may or may not be trusted by either the assignment sub-policy (RAP) to describe target or the origin, but this is not an issue who it trusts to assign which attributes to since it is storing digitally signed ACs in the whom, and the TAP to determine which repository. attributes are needed in order to access which targets. Note that the target may only trust a subset of the actual attribute authorities at the origin site, according to its 4 Note that the enforcement of dynamic delegation of RAP, and the policy specification allows for authority is currently being implemented and will be in a future release of PERMIS. 10 4th Annual PKI R&D Workshop Pre-Proceedings 5.3 Target trusts different attribute These should all be signed by the same authorities at the origin site and organisational attribute authority that is elsewhere trusted by the target. Shibboleth will then carry either signed attribute certificates or In this scenario, the target site wishes to signed SAML assertions to the target site. authorise users based on attributes assigned (Note that the latter is equivalent to the to them by different attribute authorities that model in 5.1). When the ACs are handed to are not always co-located with the origin the PDP, the RAP will check that they have site. In this case, the origin site cannot push been issued by the sole origin authority. The all the attributes to the target site (unless the TAP is then used to determine if the user has AAs have distributed them to the origin site sufficient attributes to be granted access to in the first place, which cannot be the target or not. When Shibboleth is guaranteed), so the target will need to transferring attribute certificates in the operate in pull mode and fetch the ACs that SAML assertions, the assertions do not need it needs directly from the AAs. The to be signed, though SSL encryption will be PERMIS PDP can operate in pull mode and needed if privacy protection is required. fetch all the attribute certificates that are needed from the various distributed (LDAP) 5.5 Origin wishes to distribute repositories. The SAML attribute assertions from the origin site do not need to carry any trust to multiple authorities, but attribute certificates in this instance. They target does not recognise them only need to provide the holder identity of In this scenario the target wishes to run the user, so that the target can know which standard Shibboleth but the origin wishes to ACs to retrieve. Of course, each attribute distribute the management of attributes to authority will need to let its repository different AAs i.e. to run its own PMI, with (LDAP server) be accessed by the target all the advantages this brings such as site5. Once the ACs have been retrieved, the dynamic delegation of authority. The origin target’s PDP will use the RAP to determine will be creating and storing attribute which ACs are trusted, and the TAP to certificates in its AC repository signed by determine if the user has the necessary multiple distributed attribute authorities. attributes to access the resource. However, because the target wishes to run standard Shibboleth, and wants a single 5.4 Target and/or origin do not point of trust at the origin, these ACs cannot trust origin’s attribute repository be passed to the target. Therefore the origin but target trusts origin as a single site should run a PDP with its own RAP to attribute authority validate that the ACs are issued in accordance with its own policy. This will In this scenario the origin cannot store validate the stored attribute certificates, unsigned attributes in its repository, but extract the attributes that are trusted and rather should store digitally signed attributes pass these to the local Shibboleth origin in its (LDAP) repository. The exact format server for transfer in signed SAML attribute of these could be X.509 attribute certificates assertions to the target. The target site can or (long lived) SAML attribute assertions. then run the standard Shibboleth authorisation module, or for finer grained 5 Note that if a site’s firewall prevents the LDAP control can run its own PDP and TAP, as in protocol from passing through, there are several http 5.1, to determine if the user is to be granted to ldap gateways available that allow the firewall to access or not. be tunnelled through on port 80. 11 4th Annual PKI R&D Workshop Pre-Proceedings 6 User Privacy Issues identity of the user. With a group identity One of the limiting factors of X.509 attribute the target site would only be able to profile certificates (ACs) is that they bind the the whole group, and would not be able to attributes to the holder, and if the holder is differentiate between different group identified by their real name in the AC e.g. members, or know how many members {CN=David Chadwick, OU=Computing were in the group. Laboratory, O=University of Kent, C=GB} then the user’s privacy is (at least partially) Secondly, the holder can be identified lost. There are a number of solutions to this indirectly by reference to their X.509 public problem. X.509 ACs allow holders to be key certificate. In this case the attribute identified in a number of different ways. certificate holds the serial number and issuer Firstly, they can be identified by a name of the user’s public key certificate e.g. distinguished name (DN). However, this DN {x509serialNumber=123456 + x509issuer = does not need to be the real name of the {OU=Some CA, O=Some Org, C=US}. The holder or indeed in any way be similar to the limitations of this method are that the user holder’s real name. It can be a pseudonym must be PKI enabled, which of course, many rather than their real name e.g. are not; and that, depending upon the {CN=123456789}, or even a group name contents of the user’s public key certificate, e.g. {CN=Programmer, OU=Computing the user might be identified via this. Laboratory, O=University of Kent, C=GB}. This opaque name only needs to have Finally, the holder can be identified meaning to the issuing site. The mapping indirectly by reference to the hash of a between the user’s login/authentication public key that they hold. This is now identity and AC holder identity would be effectively a random number, giving good performed at authentication time by the privacy protection. The user can prove origin site’s authentication server. It is ownership of the attribute certificate by important to note that the binding between digitally signing a challenge provided by the the pseudonym in the AC and the origin authentication server, which can then authentication name of the human user is provide this AC to the target site. The handled not by normal PKI registration restrictions are that the user needs to be procedures, but by the origin authentication using some form of asymmetric system, so that the target site’s trust in user cryptography, has generated their own authentication has to be placed in the origin private/public key pair, has created a self site’s systems and not in a trusted third party signed certificate with a random DN and CA. Further, the use of pseudonyms or does not have a corresponding X.509 public group names will make it much more key certificate identifying him/her. The main difficult for independent AC issuers to limitation from a privacy perspective is that participate in distributed trust management, the target site can profile the user, without since they will need to liaise with the origin knowing the actual identity of the user, since site to know which opaque names have been the same public key hash is used each time. given to which users. In all these cases there is a trade-off between The difference between using a pseudonym the “degree of anonymity” and the “quality and a group identity is that in the former of issuance”. At one extreme we have case the target site would be able to profile dynamically generated Shibboleth short the user, without knowing the real physical lived signed SAML attribute assertions that 12 4th Annual PKI R&D Workshop Pre-Proceedings provide anonymity but require a trusted message sent by the origin site, long lived directory to store the user’s attributes. At the ACs may have the overhead of requiring other extreme we have long lived ACs revocation list processing, depending upon where each attribute authority can issue its how they are stored and distributed. If the own attributes in a controlled manner, but ACs are stored in a repository under the without any privacy protection. At various control of the issuer, and are retrieved from points in the middle we have long lived ACs there by either the Shibboleth origin or with various forms of privacy protection target sites, or directly by the target’s PDP, (pseudonyms, group names and public key then a revocation list may be avoidable identifiers) where the AA or authentication providing the issuer deletes the ACs when system maps the user’s name into a privacy they need to be revoked, and third parties protected one. are not able to surreptitiously write them back again. In this way the revoked ACs In addition to protecting the identity of the will not be available to the PDP when either AC holder, the AC issuer name may also be it or the Shibboleth components try to protected in the same ways as above. Note retrieve them. If on the other hand the ACs that the name of the SOA may be privacy are not stored in a repository under the protected or pseudonymised in some way, control of the issuer, for example, they are but the target PDP will need to know who distributed directly to their holders, then this name actually belongs to if it is to be standard attribute certificate revocation lists configured as a root of trust. The privacy of (ACRLs) will be needed, and the issuer will the embedded attributes may be protected by need to periodically update them, in exactly encryption, as described in [3] and [7]. the same way as for public key certificate Different attributes can be encrypted for CRLs. The PDP will need to ensure that it different target sites. The main disadvantage has a current ACRL when validating the of encrypted attributes is that the issuer ACs that have been presented to it. This will needs to know in advance, when creating the cause some performance overhead at the AC, who the targets are going to be. This of target site. Short lived ACs on the other course may not always be possible with hand do not need ACRLs to be published, relatively long lived ACs, in which case SSL just as the short lived SAML assertions do encryption of the communications link is a no require them. Whilst short lived ACs do better option for attribute privacy. not have the distributed trust management benefits of long lived ones (one cannot 7 Revocation and Performance expect human managers to issue ACs to Issues their staff daily, whilst automated issuing The signed SAML assertions of Shibboleth servers have the same trust related problems do not need to be revoked due to their short as existing Shibboleth implementations), life times. Attribute certificates on the other they do have a significant performance hand are expected to have a relatively long benefit over signed XML messages [8] [9], life time, according to the so they might still be worthy of privileges/attributes being allocated. For consideration in this respect. example, one might expect a “student” attribute certificate to be valid for an entire 8 Conclusions academic year. Whilst signed SAML We have shown how a distributed, finer attribute assertions have the performance grained and more functional trust model can overhead of requiring a digital signature per be added to Shibboleth, to increase the 13 4th Annual PKI R&D Workshop Pre-Proceedings latter’s flexibility and authorisation decision [6] OASIS. “eXtensible Access Control making capabilities. We have further shown Markup Language (XACML)” v1.0, 12 Dec how the model can support target and origin 2002, available from http://www.oasis- sites using different combinations of open.org/committees/xacml/ centralised and distributed trust models, and [7] S. Farrell, R. Housley. “An Internet different assumptions concerning the Attribute Certificate Profile for trustworthiness of the origin’s attribute Authorization”. RFC 3281, April 2002 repository. We have implemented this [8] Mundy, D. and Chadwick, D.W., "An distributed trust model in Shibboleth by XML Alternative for Performance and combining it with the PERMIS authorisation Security: ASN.1", IEEE IT Professional, infrastructure and X.509 attribute Vol 6., No.1, Jan 2004, pp30-36 certificates. Finally we have argued that user [9] “Fast Web Services,” P. Sandoz and privacy does not need to be compromised colleagues, Aug 2003, available from per se by using long lived X.509 attribute http://java.sun.com/developer/technicalArtic certificates instead of short lived digitally les/WebServices/fastWS/ signed SAML attribute assertions, although it is certainly more difficult to fully protect a user’s privacy in the former case. 8 Acknowledgements The authors would like to thank the UK JISC for funding this work under the SIPS project. 9 References [1] Scot Cantor. “Shibboleth Architecture, Protocols and Profiles, Working Draft 02, 22 September 2004, see http://shibboleth.internet2.edu/ [2] D.W.Chadwick, A. Otenko, E.Ball. “Role-based access control with X.509 attribute certificates”, IEEE Internet Computing, March-April 2003, pp. 62-69 [3] ISO 9594-8/ITU-T Rec. X.509 (2001) The Directory: Public-key and attribute certificate frameworks [4] David Chadwick, Sassa Otenko, Von Welch. “Using SAML to link the GLOBUS toolkit to the PERMIS authorisation infrastructure”. Proceedings of Eighth Annual IFIP TC-6 TC-11 Conference on Communications and Multimedia Security, Windermere, UK, 15-18 September 2004 [5] OASIS. “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1”, 2 September 2003 14 4th Annual PKI R&D Workshop Pre-Proceedings Attributes, Anonymity, and Access: Shibboleth and Globus Integration to Facilitate Grid Collaboration Von Welch,1 Tom Barton,3 Kate Keahey,2 Frank Siebenlist2 1 National Center for Supercomputing Applications, University of Illinois 2 Mathematics and Computer Science Division, Argonne National Laboratory 3 Networking Services & Information Technologies, University of Chicago Abstract protecting individual privacy while still providing basic security services to system In this paper we describe our work in owners. progress to integrate the Shibboleth SAML- based framework and Globus Toolkit’s PKI- In this paper, we present our work to address based security infrastructure. The result will this issue by integrating two widely accepted provide identity federation and attribute- technologies: Shibboleth [20], an Attribute based policy enforcement for Grids that Authority service developed by the Internet2 leverages the Shibboleth system being community for cross-organization identity deployed on campuses. We provide an federation, and the Globus Toolkit’s [10] overview of both Shibboleth and the Globus Grid Security Infrastructure (GSI) [26]. Our Toolkit, present our motivating use cases, project, which is funded by the NSF and describe our planned integration work. National Middleware Initiative [16], is known informally as “GridShib” [11]. The 1 Introduction objective is to provide mechanisms whereby a Grid service can authenticate a user using As virtual organizations (VOs) [9] GSI, determining the address of the increasingly turn into distributed multi- Shibboleth attribute service in the process, institutional collaborations, secure and then obtain from the Shibboleth service authentication and authorization become a the select user attributes that the Grid growing challenge. In the existing Grid [8] service is authorized to see. Attributes infrastructure to support VOs, these obtained in this way can then be used by the mechanisms are typically based on the Grid service in making authorization identities of the interacting entities. While decisions. this approach is simple and intuitive, as VOs expand, it becomes impractical to In Section 2, we describe Shibboleth and the administer. VO membership may change relevant security portions of the Globus dynamically, rights may be granted to Toolkit. Section 3 introduces the use cases entities on a periodic basis, or a user’s role we plan to address. In Section 4 we discuss in an organization might dynamically our plans for the Globus-Shibboleth evolve. Such factors make it more practical integration, describing modes of usage, to express users’ rights based on their other technical details, and planned attributes, such as institutional affiliation or implementation. In Section 5 we compare role in a collaboration, rather than identity related technologies. In Section 6 we alone. summarize our plans and conclude the paper. Indeed, it may be desirable to enable anonymous interactions between users, thus 15 4th Annual PKI R&D Workshop Pre-Proceedings 2 Background policies on the release of these attributes, allowing the user to specify which In this section we provide an overview of targets can access which attributes. The the two software products relevant to our Shibboleth Attribute Authority retrieves work: Shibboleth and the Globus Toolkit. A attributes from an organizational more detailed description of Shibboleth [20] authority and provides them in the form and the Globus Toolkit [10] can be found on of SAML assertions. As is the case with the individual Web sites. We also describe the Handle Service, the Attribute the authentication standards used by each of Authority is intentionally neutral to the these software systems. specific implementation of the organizational attribute service; LDAP is 2.1 Shibboleth typically used today Shibboleth is a system that asserts attributes • Target Resource: The target resource about a user between organizations. More includes Shibboleth-specific code to precisely, it asserts attributes between the determine the user’s home organization user's home organization and organizations and hence which Shibboleth attribute hosting resources that may be accessible to authority should be contacted for the the user. By using an attribute-based user, to retrieve attributes regarding the authorization model, the Shibboleth user, and to make authorization architecture is able to protect user privacy decisions based on those attributes. better: identifying information may, but need not, be among the attributes presented In normal Shibboleth usage, a new handle about the user. token is acquired each time the user accesses a different resource. A handle token can be Shibboleth can be conceptually regarded as reused on returning to a resource for a comprising three components: relatively short period of time. Each handle • Handle Service: The Handle Service token has a different unique identifier for the authenticates users in conjunction with a user that is meaningful only to the local organizational authentication Shibboleth attribute authority. As a result, a service and issues to the user a handle target resource cannot rely on the handle to token. The handle token (comprising a learn the true identity of a Shibboleth user, SAML authentication assertion [19]) is a nor can it correlate subsequent accesses as bearer credential containing an coming from the same user. identifier, or handle. The Handle Service The current implementation of Shibboleth is intentionally neutral to the choice of (version 1.2) is primarily designed to the organizational authentication function with Web applications (i.e., mechanism and can function with almost standard Web servers and browsers). Plans any such service (e.g., LDAP [25]). for future implementations (starting with • Attribute Authority: When a user version 1.3) include support for non-Web requests access to a target resource, he applications. presents his handle token. The resource Figure 1 shows the typical operation of then presents the user’s handle token to Shibboleth. A number of steps not relevant the attribute authority and requests to this paper are omitted for clarity. attributes regarding the user. The attribute authority enforces privacy 16 4th Annual PKI R&D Workshop Pre-Proceedings whether communication of the requested user attributes is allowed. If so, the requested attribute values are retrieved. 8. The Shibboleth attribute authority casts the attributes in the form of a SAML attribute assertion and returns the assertion to the target resource. 9. (Not shown) After receiving the attributes from Shibboleth, the target resource makes an authorization decision regarding the user's request based on those attributes. Figure 1: Simplified Shibboleth architecture and 2.2 Globus Toolkit typical usage. Steps are described in the text. The Globus Toolkit provides basic The steps shown in Figure 1 are as follows: functionality for Grid computing [8], with 1. The user connects and authenticates to services for data movement and job the Handle Service. submission, and a framework on which higher-level services can be built. The Grid 2. The Handle Service uses a local organizational authentication service to in general has been adopting Web services verify the user’s authentication technologies, and this trend is reflected in recent versions of the Globus Toolkit in information. following the Open Grid Services 3. The Handle Service creates a new handle Infrastructure [24] and now the Web to identify the user. This handle is Services Resource Framework [29] registered with the attribute authority so standards. This convergence of Grid and that it can be mapped to the user’s Web services was part of our motivation for attributes when a request from a resource adopting Shibboleth in our project (which arrives. uses the SAML standard). 4. The handle is placed into a handle token and returned to the user. The Grid Security Infrastructure, on which the Globus Toolkit is based, uses X.509 5. The user sends a request to a target identity certificates [12] and X.509 proxy resource and presents the handle token. certificates [23, 27]. In brief, these 6. The resource examines the handle token certificates allow a user to assert a globally to determine which Shibboleth service unique identifier (i.e., a distinguished name can provide attributes about the user. It from the X.509 identify certificate). contacts that Shibboleth service and requests attributes, providing the handle We note that in Grid scenarios there is often token to identify the user. a clear separation between the certificate 7. After validity checks have been authorities (CAs), which are the authorities performed on the handle token and the of identity, and the authorities of attributes handle has been mapped to the user’s or authorization. For example, in the case of identity, the applicable attribute release the DOE SciDAC program [18], a single policy for that resource is checked CA, the DOE Grids CA [3], serves a broad 17 4th Annual PKI R&D Workshop Pre-Proceedings community of users, while the attributes and In this scenario, authorized users of the Grid rights for those users are determined by their service are located at one or more campuses individual projects (e.g., National Fusion and can be described by some campus- Grid, Earth Systems Grid, Particle Physics oriented attribute (e.g., chemistry professor). Data Grid). Verifying this attribute at their home institution authorizes user access to the Grid Authorization in the Globus Toolkit is based services. on access control lists for each resource that specify the identifiers of the users allowed to An example of where this service could be access the resource. Higher-level services to applied in a Grid context is TeraGrid [1]. provide richer authorization exist; we Each site on TeraGrid could operate a discuss these, and their relationship to this Shibboleth service in order to identify their work, in Section 5. staff and user community. This would enable TeraGrid resources to be easily 2.3 GridLogon/MyProxy available to the entire TeraGrid community without having comprehensive access GridLogon is a credential service being control lists maintained on the resource. developed at NCSA as an extension to the popular MyProxy service [15]. MyProxy is a credential management service and is the de facto mechanism used to provide security to Grid portals worldwide. Simply put, GridLogon acts as an online- CA, authenticating the user through a variety of mechanisms and issuing (short- lived) X.509 identity credentials suitable for use with Grid resources. GridLogon will provide a pluggable authentication mechanism to allow for the use of different Figure 2: Scenario showing users being authorized local authentication systems, such as based on their campus-assigned attributes. username/password, One-Time-Password, 3.2 Project-Operated Kerberos, and Public Key. Shibboleth Service 3 Motivating Use Cases Figure 3 depicts a different scenario, where In this section, we describe the use cases we the project deploys and operates its own wish to support with our work. attribute authority. This scenario has the benefit that the project can freely assign 3.1 Project Leveraging Campus attributes and add users as it wishes, without Attributes involving campus administration staff. However, the project must itself operate the The first scenario, shown in Figure 2, Shibboleth service, a critical requirement resembles the basic model in which from the perspective of both security and Shibboleth is used today, except that the reliability. This approach is beyond the target resource is a Grid service instead of a scope or capabilities of many projects. Web-based application. 18 4th Annual PKI R&D Workshop Pre-Proceedings While we believe this hybrid approach to be the best of the three scenarios, it does require some form of administration delegation capabilities that is not present today. We address this issue in Section 4.3. 4 GSI-Shibboleth Integration Our work comprises five major components: • Assertion Transmission – to enable the transmission of assertions from the Shibboleth service to the Grid software and ultimately the Grid runtime Figure 3: Scenario showing Shibboleth service authorization decision-making operated by a project. component. 3.3 Campus-Operated, Project- • Attribute Authority – to enable discovery Administered Approach of the appropriate attribute authority for a user in the Grid context. Since Grid The scenario shown in Figure 4 is a hybrid resources serve users from multiple of the two preceding scenarios. It empowers organizations, a mechanism is needed to the project to administer its own attribute determine which organization’s space while allowing the Shibboleth service Shibboleth service is authoritative for a to be maintained by campus staff who are particular user. expert in running such services. • Distributed Attribute Administration – to manage subsets of an attribute space served by a Shibboleth service by projects outside the domain operating the Shibboleth service (as described in Section 3.3). • Pseudonymous Interaction – to extend to Grids the pseudonymous interaction provided by Shibboleth. • Authorization – to provide a mechanism that is integrated with the Globus Toolkit and can take advantage of the attributes. 4.1 Assertion Transmission The fundamental engineering problem that Figure 4: Scenario showing hybrid mode of must be solved is how to transmit user operation, with the campus operating the attributes from a Shibboleth attribute service Shibboleth service and the project administering to the Grid resource so that an authorization its portion of the attribute space. 19 4th Annual PKI R&D Workshop Pre-Proceedings decision can be made utilizing those the upcoming release of Shibboleth (version attributes. 1.3) will support a generalized version of this mapping feature capable of supporting Two fundamental modes of operation DNs, which will solve the basic problem of address this problem: mapping identifiers. • Pull mode: The target Grid service, after authenticating the user, will contact the 4.2 Attribute Authority appropriate Shibboleth service to obtain Discovery attributes regarding the user. This is One issue in distributed systems that serve analogous to normal Shibboleth users from multiple communities is operation today, as described in Section determining which organization a particular 2.1. user is from and hence the organization • Push mode: The Grid user, before whose attribute authority that can provide contacting a target service, will contact attributes regarding the user. This is often an appropriate Shibboleth service to referred to as the “Where are you from?” obtain attributes and then convey those (WAYF) problem. to the target Grid service at the time of Shibboleth currently addresses this problem making a request. This is analogous to by asking users to identify their home how other attribute authority systems in organization when they attempt to access the the Grid context work today, described target resource. In its current model of in Section 5. supporting interactive Web browser-based The pull mode of operation has the applications, this approach is acceptable. In advantage of being more easily deployed; the Grid context, however, where the user since clients of services are not affected and may be using client software that does not do not even need to know Shibboleth is support this level of interactivity or the involved in their decision-making. However, client may be an unattended batch job, we as we describe in the subsequent section on need a different approach. Attribute Authority discovery, the push We will explore the following possible mode has the advantage of allowing a user solutions: to select a particular role. Hence we plan on implementing both, to allow for flexible • Use the push mode of operation, deployment to meet the requirements of described in Section 4.1 and have the different projects. user select the attribute authority to contact. This approach has been taken by Regardless of the mode chosen, there exists other systems, such as VOMS described the issue of federating the Grid identities, in Section 5.1. The main drawback is which consist of X.509 distinguished names that it requires modification of client (DNs), with the local identities used by the behavior or software, which can present organization operating the Shibboleth a deployment challenge. service. This federation will require that a mapping be performed between the DN and • Place a pointer (e.g., a hostname) to the the local site identifier. Shibboleth, as attribute authority to contact in the user’s described in Section 2.1, already performs a X.509 identity certificate. This solution similar mapping from the handle issued by requires cooperation of the CA issuing the Handle Service to the local identity, and the user’s identity credentials, which 20 4th Annual PKI R&D Workshop Pre-Proceedings may not always be available, and also This attribute management model does not binds attribute information to the user’s support resource targets wanting to use identity credential, which may raise attributes that are asserted by other problems if the lifetimes of these two authorities. One example is an issue that is elements are not in synch. already being faced by the Shibboleth community and is known as the “IEEE • Place a pointer to the attribute problem”: having universities provide IEEE authority’s location in the user’s proxy membership status to allow resource targets certificate. Since the user can create to authorize based on their IEEE proxy certificates fairly easily and with membership rather than on their campus short lifetimes, this approach solves a affiliation. While the authoritative party for number of problems with having the the attributes, IEEE in this case, could issuing CA place information in longer- establish its own Shibboleth service, this term identity certificates. The actual approach may not always be desirable placing of the information could because some organizations may not have probably be automated, and users could the resources or skills to operate a highly select from different attributes available secure attribute authority service. authorities, and even multiple authorities, depending on the specific A new privilege management system called role or roles they want to adopt. Signet [21], which is being developed by a working group of the Internet2 Middleware A related challenge that we will explore is a Initiative, supports the distributed scenario where a user may be acting in a administration of privileges. Shibboleth- role that combines attributes from multiple enabled access to Signet is planned, which organizations or from the project and an will enable authorities outside of the organization. In this scenario the user’s administrative domain in which a Signet attributes would come from multiple instance is operated to be delegated the Shibboleth services. It remains unclear at ability to manage a portion of the attribute time whether this is a true requirement for a space that can be asserted by that domain’s user community, so our exploration of this attribute authority. This arrangement has the problem may be minimal. potential to support the use case described in Section 3.3. 4.3 Distributed Attribute Administration In collaboration with the Signet development team, we will explore the The current Shibboleth attribute possibility of allowing administrative management paradigm assumes that the delegation of the attribute space in a single complete attribute space asserted by a attribute authority service among multiple particular attribute authority is managed organizations as a means to solve this within a single administrative domain. This problem. model makes sense when all the attributes are concerned with the user’s role in the 4.4 Pseudonymous Access single domain; for example, if the administrator works for the user’s university Shibboleth allows for pseudonymous access and the attributes all concern the user’s as part of its normal operation. To provide position at the university. anonymity in the Grid context, we will integrate the GridLogon service with 21 4th Annual PKI R&D Workshop Pre-Proceedings Shibboleth and the Globus Toolkit. As we provide attributes received from Shibboleth described in Section 2.3, the GridLogon to those external authorization services in service issues X.509 certificates to order to allow them to incorporate those authenticated clients. We will implement an attributes in their decision-making process. extension to GridLogon module that issues an authenticated client a set of credentials In parallel with our GridShib effort, the with a pseudonym identifier, which will Globus Toolkit team has also started work make the GridLogon service essentially act on a more ambitious authorization- as the Shibboleth Handle Service normally processing framework. As the toolkit is used does. GridLogon will register the by many different Grid applications and pseudonym with the Shibboleth attribute projects worldwide, it cannot mandate service, such that subsequent queries can be specific security technologies and mapped to the user’s attributes. mechanisms, and has to adopt a modular approach to accommodate the choices made 4.5 Authorization Mechanism by those responsible for deployment. For example, identity and attribute assertions To allow for the use of attributes in the have to be supported in X.509 Identity and Globus Toolkit runtime, we need to extend Attribute Certificate, Kerberos, and SAML the current ACL-based authorization Identity and Attribute Assertion formats. mechanism to encompass attribute-based Furthermore, all these statements can either policy. We intend to leverage existing be available in local storage within the standards and implementations here to the trusted computing base of the relying party, greatest extent possible. Our implementation be pushed by other parties via SOAP will most likely be very simple at first, for headers or Proxy Certificate embedding, be example, using attributes in place of pulled from online services, or external identities to map users to local accounts. attribute and authorization services can be queried through Shibboleth/SAML call-out We will explore the integration of XACML interfaces. [6] with the Globus Toolkit security runtime, with a mapping of SAML attribute In the first step of this authorization assertions to XACML attribute assignments processing, the received and collected as described in [14]. The result will be a assertions with their associated issuers are Web services runtime that can make verified and validated. The resulting authorization decisions about the user’s attribute statements with their issuer-subject invocation request of the Web service information are subsequently translated and operations based on the Shibboleth user’s mapped by mechanism specific Policy attribute and XACML policy rules. The aim Information Points (PIPs) into a common is to make the attribute retrieval and the format that is presented to the Policy evaluation and enforcement of the Decision Point (PDP). Our GridShib effort authorization policy transparent to the should be able to leverage this authorization application. framework development work. The Globus Toolkit currently supports an 4.6 Planned Timeline authorization callout [28], which allows external services to provide authorization The GridShib project officially began in decisions for Globus deployments as December 2004. Prior to that date we had described in Section 5.3. Our goal is to identified requirements and made 22 4th Annual PKI R&D Workshop Pre-Proceedings preliminary project plans. We are now pseudonymous mode or have any other focusing on implementing the pull mode as provision for privacy. described in Section 4.1; we expect to have a first release by the summer of 2005 based 5.3 Akenti and PERMIS on the upcoming release of Shibboleth Akenti [22] and PERMIS [2] are (version 1.3) and a post-4.0 version of the authorization systems that have been Globus Toolkit. Enabling the push mode and integrated with the Globus Toolkit through pseudonymous access will follow in 2006. the use of authorization callouts [13,28]. Both Akenti and PERMIS allow for the use 5 Related Work of X.509 attribute certificates to make Our work is distinguished from related work attribute-based authorization decisions. We mainly through the Shibboleth support for envision our work as being complementary pseudonymous interaction, its fine-grained to these systems. Our focus falls on the attribute release policy, and its existing technology to transport SAML assertions broad support base in the Internet2 from the Shibboleth attribute authority to the community. Globus Toolkit-based services, whereas these systems are designed primarily as 5.1 VOMS authorization decision makers. We envision a mode of operation in which these systems The virtual organization management can be used to provide rich authorization service (VOMS) [5] was developed by the capabilities using Shibboleth-issued SAML European Data Grid project to allow for assertions in addition to the X.509 attribute attribute-based authorization to the Globus certificates they use today. Toolkit job management services. It uses X.509 attribute certificates [7] in a push 5.4 Signet mode to assert attributes in a modified version of the Globus Toolkit. The Signet privilege management system [21] is being developed by a working group We believe that Shibboleth, with its use of of the Internet2 Middleware Initiative. SAML, will be more easily interoperable Signet can manage privileges that are with Web services-based technologies expressed as attributes asserted by emerging in the Grid community. VOMS Shibboleth. Signet itself is planned to be also does not support a pseudonymous “Shibbolized” to support delegation of mode, nor does it have any other provisions privilege management beyond the bounds of for privacy support. a single organization. 5.2 CAS As discussed in Section 4.3, we plan to collaborate with the Signet team, in order to The Community Authorization Service enable Signet to manage the access policy to (CAS) [17] is similar to Shibboleth in its use Grid resources. of SAML assertions. However CAS operates at the level of capabilities rather than 5.5 ESP-Grid Project attributes; that is, instead of expressing abstractly what someone is, CAS expresses The ESP-Grid project [4] is evaluating how explicitly what actions they are allowed to Shibboleth could be used to benefit Grid take. CAS also does not support a authentication. We have met with the members of the ESP-Grid project and will 23 4th Annual PKI R&D Workshop Pre-Proceedings stay in contact, sharing experiences and tbarton@uchicago.edu results of our work. Kate Keahey 6 Conclusion keahey@mcs.anl.gov We have described the motivations for Frank Siebenlist identity federation and for attribute-based franks@mcs.anl.gov authorization in Grids. We have described our plans for addressing these motivations Von Welch through integration of Shibboleth and the vwelch@ncsa.uiuc.edu Globus Toolkit in order to produce a system capable of enabling attribute-based authorization in Grids, leveraging existing References campus Shibboleth infrastructure, and 1. Catlett, C. The TeraGrid: A Primer, allowing for pseudonymity. 2002. www.teragrid.org. 2. Chadwick, D.W. and Otenko, A., The Acknowledgments PERMIS X.509 Role Based Privilege Management Infrastructure. 7th ACM This work is funded by the NSF National Symposium on Access Control Models Middleware Initiative, under award SCI- and Technologies, 2002. 0438424. 3. DOEGrids Certififcate Service, Our work would not be possible were it not http://www.doegrids.org, 2004. for our collaboration with the Internet2 4. ESP-GRID – Evaluation of Shibboleth Shibboleth development team chaired by and PKI for GRIDS. http://e- Steve Carmody. science.ox.ac.uk/oesc/projects/index.xml .ID=body.1_div.20, 2004. We also thank Ian Foster and Ken 5. EU DataGrid, VOMS Architecture v1.1. Klingenstein for their advice and guidance. 2003. http://grid- “Globus Toolkit” is a registered trademark auth.infn.it/docs/VOMS-v1_1.pdf. of the University of Chicago. 6. eXtensible Access Control Markup Language (XACML) 1.0 Specification, The submitted manuscript has been created OASIS, February 2003. by the University of Chicago as Operator of http://www.oasis- Argonne National Laboratory (“Argonne”) open.org/committees/xacml/ under Contract No. W-31-109-ENG-38 with 7. Farrell, S., and Housley, R., An Internet the U.S. Department of Energy. The U.S. Attribute Certificate Profile for Government retains for itself, and others Authorization. RFC 3281, IETF, April acting on its behalf, a paid-up, nonexclusive, 2002. irrevocable worldwide license in said article 8. Foster, I., and Kesselman, C. (eds.). The to reproduce, prepare derivative works, Grid 2: Blueprint for a New Computing distribute copies to the public, and perform Infrastructure. Morgan Kaufmann, 2004. publicly and display publicly, by or on 9. Foster, I. Kesselman, C., and Tuecke, S. behalf of the Government. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. Author Contact Information International J. Supercomputer Applications, 15(3), 200–222, 2001. Tom Barton 24 4th Annual PKI R&D Workshop Pre-Proceedings 10. Globus Toolkit. http://www.globus.org/, 22. Thompson, M., Johnston, W., 2004. Mudumbai, S., Hoo, G., Jackson, K., and 11. GridShib Project Web site, Essiari, A., Certificate-based Access http://grid.ncsa.uiuc.edu/GridShib Control for Widely Distributed 12. Housley, R., Polk, W., Ford, W., and Resources. 8th Usenix Security Solo, D., Internet X.509 Public Key Symposium, 1999. Infrastructure Certificate and Certificate 23. Tuecke, S., Welch, V. Engert, D., Revocation List (CRL) Profile. RFC Thompson, M., and Pearlman, L., 3280, IETF, April 2002 Internet X.509 Public Key Infrastructure 13. Keahey, K., Welch, V., Lang, S., Liu, B. Proxy Certificate Profile, RFC 3820, and Meder, S.. Fine-Grain Authorization IETF, 2003. Policies in the Grid: Design and 24. Tuecke, S., et. al. Open Grid Services Implementation. In 1st International Infrastructure (OGSI) Version 1.0, Workshop on Middleware for Grid Global Grid Forum, 2003. Computing, 2003. 25. Wahl, M., Howes, T., and Kille, S., 14. Lorch, M., Proctor, S., Lepro, R., Lightweight Directory Access Protocol Kafura, D., and Shah, S., First (v3), RFC 2251, IETF, 1997. Experiences Using XACML for Access 26. Welch, V., Siebenlist, F., Foster, I., Control in Distributed Systems, ACM Bresnahan, J., Czajkowski, K., Gawor, XML Security Workshop, October 2003. J., Kesselman, C., Meder, S., Pearlman, 15. Novotny, J., Tuecke, S., and Welch, V., L., and Tuecke, S., Security for Grid An Online Credential Repository for the Services. In 12th IEEE International Grid: MyProxy. In Proceedings of the Symposium on High Performance Tenth International Symposium on High Distributed Computing, (2003). Performance Distributed Computing 27. Welch, V., Foster, I., Kesselman, C., (HPDC-10), IEEE Press, August 2001 Mulmo, O., Pearlman, L., Tuecke, S., 16. NSF Middleware Initiative (NMI). 2004. Gawor, J., Meder, S. and Siebenlist, F.. www.nsf-middleware.org. X.509 Proxy Certificates for dynamic 17. Pearlman, L., Welch, V., Foster, I., delegation. In Proceedings of the 3rd Kesselman, C. and Tuecke, S., A Annual PKI R&D Workshop, 2004. Community Authorization Service for 28. Welch, V., Ananthakrishnan, R., Meder, Group Collaboration. IEEE 3rd S., Pearlman, L., and Siebenlist, F., Use International Workshop on Policies for of SAML for OGSA Authorization Distributed Systems and Networks, (work in progress), Global Grid Forum, 2002. May 14, 2004. 18. Scientific Discovery through Advanced 29. WS-Resource Framework. Computing (SciDAC), http://www.globus.org/wsrf/, http://www.scidac.org, 2001. http://www.oasis- 19. Security Assertion Markup Language open.org/committees/tc_home.php?wg_a (SAML) 1.1 Specification, OASIS, bbrev=wsrf, 2004. November 2003. 20. Shibboleth Project, Internet2, http://shibboleth.internet2.edu/ 21. Signet, http://middleware.internet2.edu/signet/, 2004. 25 4th Annual PKI R&D Workshop Pre-Proceedings XPOLA – An Extensible Capability-based Authorization Infrastructure for Grids Liang Fang and Dennis Gannon Computer Science Department, Indiana University, Bloomington, IN 47405 Frank Siebenlist Mathematics and Computer Science Division, Argonne National Laboratory, Argonne, IL 60439 {lifang,gannon}@cs.indiana.edu, franks@mcs.anl.gov ABSTRACT and sometimes impossible to stay with this supercomputer- There is great need for a secure, fine-grained, efficient, and centric model. For example, when a project has an user-friendly authorization infrastructure to protect the educational outreach program that encourages thousands of services in Grid community. Grid users and administrators grade school students to use services provided by the still have to deal with authentication and authorization issues research Grid, we cannot assume these students all have in the traditional supercomputer-centric fashion, especially Grid accounts on central resources. Indeed, for any research with the host account maintenance and certificate collaboration that does not have a strong centrally managed management. This paper proposes a capability-based organization that can exert influence over resource providers, infrastructure that provides a fine-grained authorization creating user accounts and managing Grid tools like Globus solution to Web service deployments, and also manages to can be a serious administrative problem if it involves more hide complex security issues from regular Grid users. than a few machines. Furthermore, it gives the resource providers and Specifically, in order to obtain access to a specific remote administrators the extensibility, flexibility and convenience resource, even just temporarily, a Grid user-to-be has to go to enforce their authorization policies at the resource with through the following steps: minimal efforts. First, she needs an X.509 certificate issued by a certificate 1. INTRODUCTION authority (CA) that is trusted by the remote host. The user is 1.1 The Grid and Its Security supposed to manage her private key securely, and make Since the end of the last millennium, the Grid technologies those credentials accessible to the Grid-enabled client have profoundly changed the way scientists compute by software. supporting collaboration and resource sharing securely As an alternative, a Grid portal solution provides the across multiple domains. Interests from academia and interface to Grid services through web servers and standard industry in Grid technologies lead to a series of frameworks web browsers. This is definitely seen as a relief by the users and applications, such as the Globus Toolkit and e-Science because it frees them from the Grid security configuration [6, 11]. The emerging Grid technologies are leveraging the pains. However, the user is still responsible for loading her Web services efforts, and are guided by Open Grid Services certificate from a Grid-enabled host into a credential server, Architecture (OGSA) at the Global Grid Forum [29]. such as MyProxy, which stores the Grid users’ credentials. To realize the resource sharing across multiple domains, the From the user’s credentials, the MyProxy server derives underlying security infrastructure plays a key role. The short-lived proxy certificates [28] after receiving requests widely used Grid Security Infrastructure (GSI), first from Grid portals or other Grid-enabled applications [18]. integrated in Globus, provides secure communication, The configuration complexity is mirrored on the remote host. mutual authentication, and coarse-grained single sign-on The user will have to contact the system administrator for an (SSO) access to remote resources [7, 27]. It allows a user to account on the remote machine that she wants to use as a access her resources across administrative domains through computing resource. After being given an account with a the use of her proxy certificates, and by delegating her rights user name, she has to ask the Grid administrator to add the to remote agents that manage remote resources on the user’s mapping entry of her username and her certificate’s X.500 behalf. The assumption it is based on is that the user had an distinguished name (DN) into a gridmap file. At runtime, account on the remote host and the remote agent is able to GSI will authenticate the user and map her Grid identity to locate a mapping from the user's Grid identity to an the local account according to the gridmap file. In some associated local host account. This model has worked cases, the user may also be responsible for setting up a reasonably well for large, centrally coordinated Grids like separate hosting environment under that account. NASA's Information Power Grid [12] and NSF’s TeraGrid [3]. However, as the size and diversity of these research The administrators have the issue of maintaining an collaborations grow larger, it becomes increasingly difficult exploding number of user accounts, of which many will only 26 4th Annual PKI R&D Workshop Pre-Proceedings be used for a short time, or never be used at all. As a result, a A and the document is signed by Y, the provider of significantly number of allocated resources is wasted in this service A. way. 2. The types of services that are provided to users in this infrastructure are Web and Grid services. For example, One of the identified problems is that, in its authorization the interface to remotely execute a specific application, process, GSI does not follow the principle of least authority or an interface to push or pull data from a specific (POLA), also known as the principle of least privilege. The stream, or an interface to see a directory of objects or gridmap file authorization model is coarse-grained, and in other services. It is never assumed that the user has an most cases allows the users and the user’s delegates more account on the computers upon which these remote rights than necessary for their jobs. As a consequence, the services execute. Remote services execute under the effect of compromises is more severe than needed [15]. identity of the service provider. Typically this service Authorization frameworks, such as the Community provider identity is the identity of the scientist or Authorization Service (CAS) [18, 19, 26], VOMS [1], engineer responsible for running or maintaining the Akenti [25], PERMIS [2] and PRIMA [14] provide a set of service on behalf of his collaborators. solutions to some of these problems. Their ability to manage 3. The entire infrastructure is built on a P2P chain-of-trust fine-grained access control can limit the risks. Nevertheless, model: The extend of the capability that I am willing to the resource providers are still required to account for the provide to an unknown remote user is limited by the identity and activities of each “user”. level of trust I have in providing access to that user. I demand that any user accessing my resource will present Peer-to-Peer (P2P) technologies, such as remote file-sharing a capability token signed by me and that the community systems, present us with another use-case for collaboration authority has authenticated the user that is presenting the at the other end of the spectrum. In these “Grids”, users capability. If the service that I am providing requires the provide resources and services to anonymous clients in use of other services to do its job, I am responsible for exchange for similar access from other users. The only assuring those service providers that the capability level security guarantee the service providers have is the vague that I provide to third parties is within the bounds of the assurance that the service they are providing is limited capability provided to me by them. access to network bandwidth and personal file space. With the problems and goals described, we will first 1.2 Goals and Accomplishments introduce the basis of the capability model in the following Given that many scientists and educators have access to section. Then we will discuss several existing authorization powerful desktop systems and small servers which they systems in Grids. In section 3, our capability-based control and are either open to the Internet, or can be made authorization infrastructure, XPOLA, will be presented in visible via a proxy server, it is natural to consider the both macroscopic and microscopic views. Next, the problem of running a user-level, peer-to-peer collaboration application of our capabilities framework is discussed as it Grid that allows a group of people to share access to a applies to our Web services framework, Grid services collection of research resources. Many collaboration framework, Grid portals, and application factory services. activities already operate in this manner, but they use ad-hoc Lastly, we will list a set of challenges and the corresponding security models. work to do in the second phase. This paper describes an extension to the Grid Security 2. THE CAPABILITY MODEL AND Infrastructure that exploits the convergence of Grid standards with Web services standards. It enables one to RELATED WORK IN GRIDS build peer-to-peer Grids with reasonable security and that 2.1 Access Control Matrix, ACL and are scalable and dynamic in structure. The goal of this work Capability is not only to provide a fine-grained authorization solution to The idea of capability originates from Dennis in 1965 [4]. A Web services in Grids, but also to hide the security issues capability is an identifier that carries a set of specific access from the regular Grid users as much as possible, and to give permission policies on the referred objects. the resource providers and administrators the flexibility and convenience to enforce and modify their authorization Resource 1 Resource 2 Resource 3 policies for the resources at runtime with minimal efforts. Alice Yes No No The systems we describe have the following characteristics: Bob Yes No Yes 1. Grid resources are made available to users through capabilities: signed tokens that allow specific users Carol No Yes No limited access to specific remote resources. These Table 1 An Access Control Matrix capability tokens can take the form of documents stating that user X has the rights to interact with service 27 4th Annual PKI R&D Workshop Pre-Proceedings Illustrated in Table 1 is an access control matrix, which The Web and Grid services are loose-coupled, highly shows all the access rights of the users to a set of resources. distributed systems. The different clients and services may If we describe the table in the column order, we call it an be part of different trust domains without any initial trust access control list (ACL). For instance, the ACL of relationships. The process of trust establishment, unlike the “Resource 1” covers Alice and Bob, but not Carol. If we ones in the operating system level security, requires minimal describe the matrix by row, then each row holds the costs on communication as well as service load and maximal capabilities of a user. For example, the user Bob has the flexibility on authorization policy administration. The capabilities to access “Resource 1” and “Resource 3”, but capability model externalizes the authorization process from not “Resource 2”. A fine-grained authorization model may the service, and thus reduces a large portion of its load. choose either way when describing its access control policy For those reasons, many Grid deployments could benefit definitions. from the capability-based model. The fact that each Web Coupled with the principal of least privilege, the capability service has a standard definition document with all its model has the advantage over ACL in that it solves the operations, parameters, identifier, and location, allows one Confused Deputy problem, of which ACL is incapable, as to specify detailed authorization policies that could be proved by Hardy [10]. The “deputy” here is a program that is protected by cryptographic means. HP’s E-speak was the being executed on behalf of other programs or people with earliest capability-related effort on Web services [24]. appropriate permissions. The Confused Deputy problem Unfortunately, Lacking of commercial success, its happens when the program is somehow fooled to apply its development was halted in 2001. In the Grid community, permissions to something that it shouldn’t do. One of the authorization frameworks like CAS and VOMS, have also reasons is the “ambient authority” issue, which means the adopted a capability model explicitly or implicitly, as we program need not and cannot name the specific authority will discuss in section 2.3. that justifies the operations that it takes to sense or modify the world around it. 2.2 ACL-based Authorization Infrastructure in Grids An old example from the Confused Deputy problem is that a A cross-domain fine-grained authorization model usually printing program that audits the users’ printing activities by comprises of the nodes of clients, resources, and authorities. outputting the printing information to a log file, purposely, is In a typical ACL-based model, the authority is commonly on fooled to overwrite some important system file such as the resource side and part of the same administrative domain /etc/passwd, which leads to a security hole that allows as the resources. The resource provider often has no control attackers break in. The problem lies in the fact that the over the authority. In order to configure the authorization printing service works under two different authorities. One policy, the resource provider collaborates with the is representing the user to print his files; the other is for the administrators for the users. Usually this process is not system or system administrator to record users’ printing automated, can be cumbersome, and may involve many activities. Under each authority, it is able to do anything steps. more than what the user or the system administrator means. ACL does not solve the problem because if it looks up in the ACL, the program that is representing the administrator does Users Resource Authority have the authority to write /etc/passwd. However, in capability model, the deputy would have been given a set of capability tokens specifying what is allows to do with the Resource printing service and the logging file. Without being granted Provider the capability to write /etc/passwd, it will simply be denied Figure 1 ACL-based Authorization Infrastructure by the system. For now, we assume that the user has acquired her certificate The association of access control with objects can be and an account on the remote machine. After receiving a extended by defining a capability as the property of a user or client’s resource request, the resource node needs to verify process to carry out a particular operation. This concept was the client’s identity, after which it forwards the client’s first used in computer architectures such as the Cambridge identity to the authorization authority for an access decision CAP, the Hydra operating system for C.mmp, and the Intel concerning the targeted resource. This decision will either iAPX 432 architecture (see [13] for an excellent survey). permit or deny the client’s request. PERMIS and Akenti Capabilities have also been embedded in programming have adopted the ACL-model that works in the flow languages, such as E [16], and they seem to be especially illustrated in Figure 1 (note that Akenti can work in a important for distributed systems. Furthermore, capabilities capability-mode too). have been applied to the design and implementation of operating systems like EROS [21]. Within this ACL-based model, the resource node is explicitly responsible for authenticating and authorizing 28 4th Annual PKI R&D Workshop Pre-Proceedings every single request. When the requests are repeated in a service authenticates the user with his X.509 certificate and sequential manner from the same client, the authentication issues capabilities to authorized users. On the resource and authorization processes are thus repeated, which makes server side, with the local policies, the resource provider still this system susceptible to scalability problems and possible makes the final authorization decision, even if the user has Denial of Service (DoS) attacks. Akenti uses caching to been given the permission by the CAS server. However, the mitigate the problem, but it hurts those isolated requests at resource server will allow no more than what the capability the same time. allows. 2.3 Capability-based Authorization Even though the CAS framework supports fine-grained Infrastructure in Grids authorization, resource providers have to verify that the Another category of fine-grained authorization frameworks CAS server is to be trusted and that the community's policies works with a capability model. In such infrastructures, the match their own local policies through some out-of-band client’s possession of a capability confers an access right to a form of configuration, which is not applicable in the case of resource, according to the pre-defined policy embedded in highly dynamic services like the impromptu experimental that capability. ones that are provided by the scientist users. The workflow is as follows: the user first sends a capability Moreover, any form of centralized administration presents a request to the authorization authority. The resource provider single point of failure when being compromised or under could either approve the request or delegate his rights to the attacks. One proposed solution of having multiple replicas authority to issue the requested capability tokens. of CAS servers to address the single-point-of-failure issue Subsequently, the client sends her access requests along will statistically bring more chances of being compromised. with the capability tokens to the resource node. On the Note that the capability model itself is not perfect either. resource node, the capability token’s integrity is first Capability revocation is a thorny problem in CAS as well as verified. The policy details of the capability are then any other capability-based systems. extracted as the reference to the final authorization decision. Other fine-grained Grid authorization infrastructures are Figure 2 shows a simplified diagram of the capability model. similar to CAS or Akenti. The different approaches can be distinguished in the way they bind policies to certificates Resource Users Resource and their authorities, while the enforcement mechanisms Provider may differ slightly. (Authority) Figure 2 Capability Authorization Infrastructure As we will show in the next section, XPOLA tries to keep Besides the advantages on solving the Confused Deputy the advantages of the capability model, while solving most problem and externalizing authorization administration as of the issues associated with the capability model and other we mentioned in section 2.1, the capability-based fine-grained authorization efforts. The main difference from authorization infrastructure also has the benefit of any other existing capability-based infrastructures including reusability. The issued capability tokens are reusable for CAS is its peer-to-peer administration model that securely multiple accesses as long as their policy allows. It saves the brings maximal freedom to scientists and researchers. In the repeated authorization evaluation processes that are extreme case that all services are provided by one single user inevitable in ACL-based systems. or a service account, that user becomes the administrator, just like the role in other infrastructures. A more practical reason is that some of the Grid users, especially those scientists, have the will to build their 3. XPOLA, THE MACROSCOPIC VIEW extemporaneous experiment services and allow others to use 3.1 The Big Picture them securely without the lengthy interference of their The name of XPOLA stands for an eXtensible fine-grained system or Grid administrators. Capability allows them to authorization infrastructure that strictly conforms to the distribute their services in a peer-to-peer fashion and remove Principle of Least Authority (POLA). The design picture of the system security concerns that hinder their research. XPOLA is shown in Figure 3. The capability manager CAS is an example of a capability-based authorization (Capman) is the platform for resource providers to service. In CAS, a user must present a capability issued by collaborate with their users. Through this platform, the user’s community’s authority to the resource provider to resource users send requests to the providers for access access the resource. The CAS capability token is bound to an rights; the provider processes the requests and creates the extended proxy credential. Instead of the resource provider corresponding capability tokens. The capability manager issuing the capability directly, the provider delegates part of stores the capability tokens and supports the providers with his authorities to a community administrator. Every the functionalities for manipulating the capabilities: community has at least one central administrator to define capability generation, destruction, update, renewal, request the authorization policies and manage the service. The processing, and optionally pushing the capabilities to the users. 29 4th Annual PKI R&D Workshop Pre-Proceedings The registry service provides registration and discovery of which contain detailed authorization policy and protected by the available Web service instances. It keeps the information X’s signature. We will dissect the capability token later, but of all the registered service instances. Every time a new here we just need to know that the identity of Y is included in service is instantiated, it is supposed to register itself by the policy as one of the users. Now X advertises his service sending a Web Services Definition Language (WSDL) to Y, who will to use A. When Y tries to access A, his token document to the registry. A WSDL document contains the agent contacts the Capman service for the required detailed information needed to interact with the service capability token. If available, the token is fetched and sent instance. along with the service request to A, where the capability is to be verified. Thus the user Y is served by A, if the request If the capability of a specific resource for a specific user matches what the capability allows. exists in the capability manager’s storage, the user can fetch the capability from the manager directly and stores it in her 3.2 Attack Analysis local token agent. The token agent is an ssh-agent-like client Figure 3 can be simplified as Figure 4 to reflect the trust for interacting with the capability manager and caching the relationships between the main entities, namely the retrieved capability tokens. capability authority, the clients, the service instances, and an optional CIA service. Service Registry Provider (EPRservice A, …) Persistent CIA Storage Request create Processing Capability Community update Capability Manager Clients Services (Capman) Informative Authorities Capability Authority Request destroy Figure 4 A Simplified Trust Relationship Picture for Attack Analysis The service might be subject to various forms of illegal Token Agent Host accesses and attacks from the clients. Examples of illegal or Processing SVC malicious access attempts are: capability token Stack A 1. The user does not have a capability for the remote Service Requester resource, or has a fake or invalid capability. Figure 3 The Big Picture 2. The capability is valid, but the user applies it beyond its policy definition. For instance, the user tries to The Community Informative Authority (CIA) is an optional access some other resource that is not specified in the trusted authentication service for identity verification in the capability policy. community. It establishes trust relationships, either mutual or unilateral as required, between the users and providers. 3. The access is authorized, but the user orchestrates a Note that CIA service does not make any authorization Denial of Service attack (DoS) with the valid decisions for the providers. It is left to the providers capabilities. themselves to make their authorization decisions based on The first two situations can be handled easily by executing the provided authentication information. CIA is not the capability enforcement. The last one is a tricky problem necessary if two parties can mutual authenticate each other for capability-based systems. We need to revoke the by other means, for example, through the portal login malicious users’ capabilities at runtime while the DoS attack authentication of a trusted portal. No matter whether it takes place. works implicitly or explicitly, the CIA service is designed to The capability manager does not need much protection as address the trust bootstrap problem in an XPOLA-enabled the capability tokens are inherently protected by the Grid community. signatures from being forged or tampered. They are totally To make it better understood, let’s walk through one of the useless to any user who steals them, as the attackers’ use scenarios as a provider, X, of service A, and a service A’s identities are not specified in the policies, unless a valid user, Y. Suppose X first creates the service A on a remote user’s private key is available at the same time. host. Upon being created, the service A registers itself to a The worst case could happen is when the private key of a persistent registry. The provider then wants to distribute the provider is stolen; however we can confine the service to other people including the user Y. Through a consequences of this compromised authority to the provider Capman service, he generates a set of capability tokens 30 4th Annual PKI R&D Workshop Pre-Proceedings himself, who is merely one of the non-privilege users. Note standards from W3C and OASIS for SOAP-based Web that the providers won’t be able to blame the administrators, services. The security related elements are added to the because they themselves are responsible for the security of header section of SOAP messages, including signatures, their own resources. XPOLA is flexible in that under some references, confirmation methods, canonicalization methods, circumstances, administrators can take over the etc. authorization work by running services with special non-privilege service accounts. 4. XPOLA, THE MICROSCOPIC VIEW SOAP Message 4.1 The Capability Tokens A capability is a policy definition referring to a specific Header resource object. In XPOLA, a policy definition comprises of a delegation relationship and a set of authorization decisions Capability Token for the referred object. The capability is protected with signatures and can be encrypted if needed. Policies Formally we define a capability as follows. Assume a resource provider named X creates a capability C to delegate Signature a set of rights R on the service identified as S to a group of users P after the time of T with the duration ∆t. The Web Service Security Section capability CX is defined as (Signature, public keys, …) C = [ X , P, R, S , T + ∆t ] XPOLA has adopted the Security Assertion Markup Body Language (SAML) to express C, but it could be any policy languages, as long as the recipient, who himself set up the Figure 5 A Capability Bound to a SOAP Message policy in most cases, is able to understand it. XPOLA is Similarly, capability tokens are embedded into the header extensible to use policy definitions expressed in different section of users’ SOAP messages, as showed in Figure 5. formats or languages. The SOAP message is then signed with the user’s private key and the generated signature inserted into the Web The policy definition for the operations of Web services is service security section to protect the integrity of the SOAP specified according to their Web Services Definition message, along with the user’s public key and identity, Language (WSDL) documents. The WSDL document is the which will be verified against the capability token later. standard interface description of a Web service. 4.2 The Capability Enforcement in Web The policy must contain the following items, corresponding to the formal definition: Services The enforcement is done when the capability-enabled ● Parameter X: One or a set of the resource providers’ SOAP message arrives at the remote resource service. We X.500 distinguished names (DN) from their X.509 will identify the actual resource owner as A*, the actual certificates. resource with the identifier S*, the actual resource access ● Parameter P: One or a group of specific users’ DNs. attempt E that happens at the time T*. The original capability CA arrives at the resource as ● Parameter R: A set of authorization decisions corresponding to the concerned operations of S. C ' = [ X ' , P' , R' , S ' , T '+ ∆t ' ] ● Parameter S: A service identifier, which is an endpoint The final authorization decision is made upon reference (EPR) of a specific Web service. ● Parameter T: The lifetime of the capability. C = C ' , X = X * , S = S * , E ⊆ R , T * < T + ∆t Furthermore, the assertion will include signatures and and verification methods. When privacy is a concern, the capability should be encrypted. ∏r ∑r ≥ F . j j∈C ,C ⊆ R ri ∈R i s ri ∈ R , ri ∈ {0,1} Within the Web services framework, when a user makes secure requests to remote resources, her client program Here, Fs is the authorization threshold of the resource S and communicates with them by exchanging SOAP messages Fs = 1. When ri = 0, it means “denied”; while ri = 1 means that comply with Web services security specifications. Web “granted”. The set C is the crucial authorization decisions services security is a series of emerging XML-based security in R, which means any element rj in the set C must be 31 4th Annual PKI R&D Workshop Pre-Proceedings “granted”, in order that the access be authorized. The above 5. THE XPOLA IMPLEMENTATION AND process can be generalized as ri ∈ [0,1] and Fs ≥ 0 , when APPLICATIONS the provider is not so sure about his decision. 5.1 The Implementation In XPOLA-enabled Web services, when a user makes a The implementation work includes the development of the remote call from the client side, the client program first core package of capability tokens with an application performs a preliminary authorization check by matching the programming interface (API), the capability management capability policy with the SOAP body content and the user’s toolkits, and their applications. identity. If nothing violates the policy, it inserts the The capability’s policy core adopts the popular XML-based appropriate tokens into the SOAP header, including the security language, Security Assertion Markup Language signatures; otherwise, the client is refrained from invoking (SAML) to express policy definitions [31]. SAML addresses the request. three different use-cases. An arriving A dispatched SOAP Msg SOAP Msg 1. Single Sign-On. The ability of a user (or subject in SAML terms) to authenticate in one security domain and have that authentication respected in another domain. SOAP Sig Verification SOAP Sig Generation Authentication 2. Authorization. The ability to ask questions about and N Processing Node describe the authorization of an actor to access a resources. Valid? Fault Generation Y 3. Transactions. The ability to pass the authority to complete Token Verification Token Insertion a task from one security domain to another. Token Sig Valid? At its most basic level SAML is a language for making Authorization assertions about authentication, attributes, conditions and Owner/User Match? Processing Node authorization decisions. For example, an authentication N Fault Generation assertion typically takes the form “subject S was Policy Decision? authenticated by means M at time T.” Attributes are simply Expired? name-value pairs associated with facts about a subject. Other Authorization decisions take the form “It has been decided Processing Nodes that subject S is authorized to perform action A on resource R. Application Service SAML provides a simple protocol to ask questions like “What authorization assertions are available for this Figure 6 The Processing Stack on the Service Side subject?”, “What are the values associated with these On the resource side, when the Web service receives a attributes for this subject?”, “Is this subject allowed to remote call through a SOAP message, the processing node access this resource in the following manner?”. first authenticates it by checking the validity of the user’s signature against the whole message. If nothing is wrong, In SAML terms, each capability policy document is a the authorization processing node verifies the signature of standard SAML assertion. The capability tokens are signed the embedded capability token. It then does a series of with the provider’s private key. The public key is attached matching operations, such as the capability issuer’s DN and for verification. the actual resource provider’s DN, the actual caller’s DN XPOLA is designed with extensibility in mind. If needed, and the allowed users’ DNs, the operations specified in the we can plug-in other XML-based policy languages such as capability and the ones in the SOAP body. It also checks eXtensible Access Control Markup Language (XACML) whether the capability has expired against the time. At last, it [32], or eXtensible rights Markup Language (XrML) [33]. peels off the capability token and passes the rest of the The bottom line is, the provider can use any policy language SOAP message on to the next processing node. The detailed he wants as long as he understands his own policies. Neither diagram is showed in Figure 6. does XPOLA mandate the use of PKI to protect the The client side policy checking prevents those unauthorized capabilities. The provider may use symmetric keys to sign requests from reaching services and is able to prompt the capabilities, though in that case he needs some other appropriate error information immediately to the users. ways like Kerberos, to authenticate the users and assertions. Services thus need not waste their resources on processing XPOLA relies on XSUL to bind the capabilities to SOAP these requests. The capability checking at the service side is messages and to enforce the capability-based authorization. mainly for guarding services from malicious users who XSUL is a light-weighted SOAP engine and a general Web elude the provided authentic clients to send the invalid services framework [23]. Web service developers can write requests directly. Such attack scenarios are discussed in their own capability-enabled Web services with XSUL with section 3.2. limited effort. We have also integrated the XPOLA into GSX for building capability-enabled Grid services. GSX is an Open Grid Services Infrastructure (OGSI) [30] and Web 32 4th Annual PKI R&D Workshop Pre-Proceedings Services Resource Framework (WSRF) –compliant [34] While the proxy certificate is valid, the portal can fetch it Grid service framework based on XSUL [20]. The when the proxy certificate's owner, the portal user, wants to capability-based Grid service was assigned as homework in invoke a remote Grid service through a Grid portlet. The a distributed computing class. Turning an insecure Grid proxy certificate goes along with the remote service call to service into a capability-enabled one, was so simple that few authenticate the user, according the gridmap mechanism. student ever complaint. The authorization steps, if available, are done in the ACL style, as shown in Figure 7. The fact that our capabilities are inherently protected by themselves, allows us to use alternative ways to distribute One example of a Grid portal is the GFac portlet that works them even through unprotected means. For example, the as the client of a GFac service. The GFac service is a resource provider can use email, shared file system or even Grid-enabled application factory service that encapsulates fax to deliver capabilities to the user. non-Web services, launches them on remote hosts at run time, and presents them as Web service instances [8]. GFac To help the user, we provide a portlet-based capability has been applied to launch complicated jobs remotely in the manager and token agent build on the core capability APIs. scientific domains of biology and meteorology. We believe a user-friendly human-computer interface is vital in any security infrastructure. Many security systems Originally, GFac was a typical non-capability-based Grid fail, commercially or technically, simply because the users service. After a GFac Bio service is launched remotely by its would not or could not follow the complicated rules. The provider, a Bio service user can access the service from the capability manager as an independent Web service that Grid portal by contacting the remote service with her proxy shares the same database is also available. certificate stored in her portal user context. On the remote host, her Grid identity is first mapped to a local account, 5.2 XPOLA in Grid Portals where the authorization decision lookup is done by the GFac Grid portals are becoming very important in Grid Bio service. With no choice, the GFac service provider has deployments. They provide Grid community with a user to delegate his authority to the administrator such that he can friendly and familiar web-based interface to access their pre-configure the gridmap file and the authorization service, Grid resources. A Grid portal is made up of a cluster of before allowing the designated users to access his service. customizable display units, called portlets. A dynamically generated web page in a Grid portal is the aggregation of a The XPOLA integration moves GFac’s authorization group of portlets in a personalized layout. The Grid portlets process to the external Grid portal and avoids the could act as the clients of the remote Grid services. administrator’s authority brokering. After launching the service, the provider creates capabilities with capability A Grid portal provides its own authentication mechanism manager portlet and stores them in portal user contexts. through portal accounts bound with the users’ proxy Later, when a portal user logs in, he can simply access the certificates. Both resource providers and users, as the portal remote Bio service resource through the portlet client. The users, share the same trusted portal context. portlet automatically fetches the required capabilities from the user’s context if they are available. The remote service User authorizes the user according to the capabilities it receives. proxy Proxy GFac certificate Provider User Manager Service GFac Bio Service capability Portlet Portlet Remote Capability Proxy GFac token GFac Bio Host Manager Manager Service Service proxy proxy certificate certificate Admin Portlet Portlet Portlet gridmap capability capability proxy proxy capability Grid Portal token token token certificate certificate Authorization capability Provider User Context Service Grid Portal token Figure 7 Authorization in an ACL-based Grid Portal User Context Traditionally, when a user logs into a Grid portal with her account, the portal requests a proxy certificate from a Figure 8 Authorization in an XPOLA-enabled Grid Portal credential server, such as the MyProxy server [17], which returns a proxy certificate under the request. Usually the Because Grid portal is a trusted domain for all users, it proxy certificate has a very short period of lifetime. The implicitly plays the role of CIA by authenticating users with portal server stores the proxy certificate in the user context. their portal accounts. Grid portal makes it possible to 33 4th Annual PKI R&D Workshop Pre-Proceedings transparentize the authorization process to portal users, as 6. CHALLENGES AND FUTURE WORK illustrated in Figure 8. 6.1 Session-based Communication To summarize the scheme depicted in Figure 8: in a Performance is a big challenge in XML-based security capability-enabled GFac service, the provider first launches implementations. Fortunately there are often possible a Bio job remotely through a GFac portlet. Then he simply workarounds to address the high overhead of the XML creates a series of capability tokens for those authorized processing. The initial results of some informal tests, gives users with the capability manager portlet and stores them in an indication that a session-based communication may be a the user contexts. After that, he can invite the users who promising solution. With session-based protocols integrated have been endowed with the capabilities to use his service. in our communication stack, we expect them to lower the The authorized user logs into the portal and she will be able XML security processing overhead significantly. In the to access the remote Bio service with the capabilities second phase of our XPOLA work, we plan to implement a automatically fetched from her user context in the Grid session-based secure communication specification, based on portal; while as a naïve user, she may never know the WS-Trust, WS-SecureConversation, and on the existence of capabilities. implementation work that was previously done [5]. 5.3 Performance 6.2 Revocation The capability-based authorization infrastructure is efficient Revocation is a challenge for all capability-based systems. as it allows for the reuse of capabilities and user-level After the users acquire the capability, the provider does not administration. An authorization decision, once made, can have any effective approach to revoke it. In most be reused for multiple times. capability-based systems, a capability’s lifetime is so short that revocation is not practical, while the short lifetime may However, if we only look at the narrowest definition of also help limit the amount of damage in the case of performance, it takes about 1000 to 2000 mille-seconds for a compromise. roundtrip communication between a client and a service, as shown in Figure 9. As the number of invocations grows, we One possible solution that we are investigating is to tie the see a slightly better throughput, probably due to the internal capability to established sessions. This would allow us to optimization of Java Virtual Machine itself, but it still falls revoke a specific capability immediately, by simply in the same range. Considering the bulky SOAP header with invalidating the underlying session. security-related SAML assertions, signatures, and public keys, we are not too surprised about these observations. The 6.3 Denial of Service Mitigation reason seems to be a general problem of the Capability itself is a good mechanism for dealing with implementations on Web services security nowadays: the Denial of Service (DoS) attacks for providing fine-grained underlying XML-related operations and processing, authorization. One of the principals of DoS attack especially the canonicalization operations, are very prevention and mitigation is using the cost model – a client expensive [22]. has to pay proportionally to the amount of the accesses to a service. A capability can be regarded as a resource “currency note” to be used to pay for the service it refers to. Capability tokens also make it possible to load balance the authentication and authorization work to other machines. A more sophisticated method will be to issue or request for dynamic capability tokens in the situation of an overwhelmed service, which would match the session-based capability system design. 7. CONCLUSIONS In this paper, we introduced an efficient and user-friendly capability-based authorization infrastructure, XPOLA. It is based on user-level, peer-to-peer trust relationships, and used for building secure Web services and Grid services with the support of fine-grained authorization policy enforcement. We presented both microscopic and macroscopic views of XPOLA, and discussed its Figure 9 Throughputs of an XPOLA-enabled Web service applications. Lastly, we brought up some challenges and tentative solutions that are to be addressed in future work. 34 4th Annual PKI R&D Workshop Pre-Proceedings 8. ACKNOWLEDGMENTS [13] H. Levy, Capability-based Computer Systems, Digital We would like to thank Gopi Kandaswamy, Aleksander Press, 1984, now available at Slominski, and Yogesh Simmhan for their discussions and http://www.cs.washington.edu/homes/levy/capabook/ collaboration on the integration work of the factory service, [14] M. Lorch, D. B. Adams, D. Kafura, M. S. Koneni, A. XSOAP and GSX. We also appreciate Markus Jakobsson Rathi, and S. Shah. The PRIMA System for Privilege for his invaluable suggestions to improve the paper. Management, Authorization and Enforcement in Grid Environments. Proceedings of the IEEE 4th 9. REFERENCES International Workshop on Grid Computing, 2003. [1] R. Alfieri, R. Cecchini, V. Ciaschini, L. dell'Agnello, A. Frohner, A. Gianoli, K. Lorentey, and F. Spataro. [15] K. Keahey, V. Welch. Fine-Grain Authorization for VOMS, an Authorization System for Virtual Resource Management in the Grid Environment. Organizations. In European Across Grids Conference, Proceedings of Grid2002 Workshop, 2002. February 2003. [16] M. Miller, M. Stiegler, Open Source Distributed [2] D. W. Chadwick and A. Otenko. The PERMIS X.509 Capabilities, http://www.erights.org/index.html. role based privilege management infrastructure, Future [17] J. Novotny, S. Tuecke, V. Welch. An Online Credential Generation Comp. Syst. 19(2), pp. 27-289, 2003. Repository for the Grid: MyProxy. Proceedings of the [3] C. Catlett. TeraGrid: A Primer. Tenth International Symposium on High Performance http://www.teragrid.org/about/TeraGrid-Primer-Sept-0 Distributed Computing (HPDC-10), IEEE Press, 2.pdf. August 2001. [4] J. B. Dennis and E. C. Van Horn. Programming [18] L. Pearlman, V. Welch, I. Foster, C. Kesselman, and S. Semantics For Multiprogrammed Computations. MIT Tuecke. A Community Authorization Service for Group Technical Report MIT/LCS/TR-23, 1965. Collaboration. Proceedings of the IEEE 3rd International Workshop on Policies for Distributed [5] L. Fang, S. Meder, O. Chevassut, and F. Siebenlist. Systems and Networks, 2002. Secure Password-based Authenticated Key Exchange for Web services. ACM Workshop on Secure Web [19] L. Pearlman, C. Kesselman, V. Welch, I. Foster, S. Services, Oct.29, 2004, Fairfax, VA. Tuecke,The Community Authorization Service: Status and Future, CHEP03, March 24-28, 2003, La Jolla, [6] I. Foster, C. Kesselman. Intl J. Supercomputer California Applications, 11(2):115-128, 1997. [20] Y. L. Simmhan, Grid Service Extensions, [7] I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke. A http://www.extreme.indiana.edu/xgws/GSX/ Security Architecture for Computational Grids. Proc. 5th ACM Conference on Computer and [21] J.S.Shapiro, J.M.Smith, and D. J. Farber. EROS: A Fast Communications Security Conference, pp. 83-92, 1998. Capability System. SOSP, 1999. [8] D. Gannon, S. Krishnan, L. Fang, G. Kandaswamy, Y. [22] S. Shirasuna, A. Slominski, L. Fang, and D. Gannon. Simmhan, and A. Slominski. On Building Parallel & Performance Comparison of Security Mechanisms for Grid Applications: Component Technology and Grid Services, the 5th IEEE/ACM International Distributed Services. In CLADE 2004, Challenges of Workshop on Grid Computing, Pittsburgh, Nov. 8, Large Applications in Distributed Environments. IEEE 2004. Computer Society Press, Jun 2004. [23] A. Slominski, M. Govindaraju, D. Gannon, and R. [9] D. Gannon et al. Building Grid Portal Applications Bramley. Design of an XML-based interoperable RMI from a Web Service Component Architecture, 2004. system: SoapRMI C++/Java 1.1. In Proceedings of the 2001 International Conference on Parallel and [10] N. Hardy. The Confused Deputy, Distributed Processing Techniques and Applications, http://www.cap-lore.com/CapTheory/ConfusedDeputy. Las Vegas, NV, Jun 2001 html. http://www.extreme.indiana.edu/xgws/xsoap/ [11] T. Hey and A. E. Trefethen. The UK e-Science Core [24] Spring, Buranarach, Schrubb, and Zatuchnaya. E-speak Programme and the Grid, Future Generation Revisited. Forum on Design Languages Sep 3-7, 2001, Computing Systems, Vol 18 page 1017, 2002. Lyon, France. [12] W. Johnson, D. Gannon, B. Nitzberg. Grid as [25] M. Thompson, et al. Certificate-based Access Control Production Computing Environments: The Engineering for Widely Distributed Resources. In Proc. 8th Usenix Aspects of NASA's Information Power Grid, HPDC Security Symposium. 1999. 1999. [26] V. Welch, R. Ananthakrishnan, S. Meder, L. Pearlman, F. Siebenlist, Use of SAML in the Community 35 4th Annual PKI R&D Workshop Pre-Proceedings Authorization Service, [30] Open Grid Services Infrastructure, OGSI working http://www.globus.org/security/CAS/Papers/SAML%2 group at Global Grid Forum (GGF) 0Feedback-aug19.pdf [31] OASIS, Assertions and Protocol for the OASIS Security [27] V. Welch, F. Siebenlist, I. Foster, J. Bresnahan, K. Assertion Markup Language (SAML) V1.1 Czajkowski, J. Gawor, C. Kesselman, S. Meder, L. http://www.oasis-open.org/committees/download.php/ Pearlman, S. Tuecke. Security for Grid Services, 3406/oasis-sstc-saml-core-1.1.pdf Twelfth International Symposium on High Performance [32] OASIS, Core Specification: eXtensible Access Control Distributed Computing (HPDC-12), IEEE Press, June Markup Language (XACML) V2.0 2003. http://docs.oasis-open.org/xacml/access_control-xacml [28] V. Welch, I. Foster, C. Kesselman, O. Mulmo, L. -2_0-core-spec-cd-02.pdf Pearlman, S. Tuecke, J. Gawor, S. Meder, F. Siebenlist. [33] ContentGuard, eXtensible Rights Markup Language X.509 Proxy Certificates for Dynamic Delegation. 3rd (XrML) 2.0 http://www.xrml.org Annual PKI R&D Workshop, 2004. [34] OASIS, “Web Service Resource Framework”, March [29] Open Grid Services Architecture, OGSA working 2004. group at Global Grid Forum (GGF), https://forge.gridforum.org/projects/ogsa-wg 36 4th Annual PKI R&D Workshop Pre-Proceedings Design and Implementation of LDAP Component Matching for Flexible and Secure Certificate Access in PKI Sang Seok Lim Jong Hyuk Choi Kurt D. Zeilenga IBM Watson Research Center IBM Watson Research Center IBM Linux Technology Center P.O. Box 218 P.O. Box 218 Carson City, NV Yorktown Heights, NY 10598 Yorktown Heights, NY 10598 zeilenga@us.ibm.com slim@us.ibm.com jongchoi@us.ibm.com Abstract assertion values). However, these simplifications come at a price. Because the string-based encoding in LDAP generally does not Lightweight Directory Access Protocol (LDAP) is the predomi- carry the complete structure of abstract values, adding support for nant Internet directory access protocol and hence so is its use in new syntaxes and matching rules requires ad-hoc developments of the Public Key Infrastructure (PKI). This paper presents the design syntax parsing and matching routines. X.500 protocols, on the other and implementation of LDAP component matching which enhances hand, avoid this problem by use of ASN.1 (Abstract Syntax Nota- flexibility and security of the LDAP directory service when it is tion One) [13] encoding rules, in particular, the Basic Encoding used for the PKI certificate repositories. The component match- Rules [12]. ing together with the prerequisite ASN.1 awareness enables match- ing against arbitrary components of certificates and enables match- Though these limitations were not viewed as a significant problem ing of composite values at the abstraction layer of the underlying during LDAP’s early years, it is clear that a number of directory ASN.1 type definition. This allows searching for certificates with applications, such as PKI, are significantly hampered by these limi- matching components without the need of providing syntax spe- tations. For instance, in PKI, a certificate needs to be located based cific parsing and matching routines (flexibility), without the need upon the contents of its components, such as serial number, issuer of extracting the certificate components and storing them into sepa- name, subject name, and key usage [14]. LDAP search opera- rate attributes which become searchable but mutable (security), and tions do not understand ASN.1 types in the definition of the certifi- without the need of restructuring Directory Information Tree (DIT) cate attribute and assertion [14], because attributes and assertions to support multiple certificates per subject (manageability and per- in LDAP are encoded in octet string with syntax specific encod- formance). In this paper, we describe the architecture, key data ing rules. Not only would it require exceptional effort to support structures, and the proposed methods of enhancing interoperability matching rules such as certificateExactMatch and certificateMatch and performance of our component matching implementation in the as defined in [14], that effort would have to be repeated for each OpenLDAP open source directory software suite. We also propose matching rule introduced to match on a particular component (or the use of component matching in on-line certificate validation and set of components) of a certificate. Because of the large amount of in Web services security. Through performance evaluation of the effort each server vendor must undertake to support each new rule, OpenLDAP component matching, we show that our LDAP compo- few new rules have been introduced to LDAP since its inception. nent matching implementation exhibits the same or higher perfor- Applications had to make due with existing rules. mance compared to the previous approaches. Foreseeing the need to be able to add new syntax and matching rules Keywords without requiring recoding of server implementations, the directory community engineered a number of extensions to LDAP to address PKI, X.509 Certificate, Certificate Repository, Component Match- these limitations. The Generic String Encoding Rules (GSER) [17] ing, LDAP was introduced to be used in describing and implementing new LDAP string encodings. GSER produces human readable UTF- 8 [32] encoded Unicode [28] character string which preserves the 1 Introduction complete structure of the underlying ASN.1 type and supports reuse of the existing LDAP string encodings. Provided that an LDAP The certificate repository in Public Key Infrastructure (PKI) is a server is ASN.1 aware, i.e. it can parse values in ASN.1 encod- means of distributing certificates and Certificate Revocation Lists ing rules into its internal representation of ASN.1 value and can (CRL) to end entities. It stores certificates and CRLs and provides perform matching in that abstraction layer, it is possible to support efficient access methods to them by harnessing storage means with matching of arbitrary types without needing ad-hoc developments communication mechanisms. The directory technology stands out of parsing and matching routines. as the most befitting approach to implementing certificate repos- itories because the X.509 [14] PKI has been standardized in the The component matching [18] mechanism was also introduced to context of the X.500 recommendations as the public key based au- allow LDAP matching rules to be defined in terms of ASN.1. It in- thentication framework on the X.500 directory. troduces rules which allow arbitrary assertions to be made against selected components values of complex data types such as certifi- Lightweight Directory Access Protocol (LDAP) [10] renders cates. For example, the component matching enables matching lightweight directory service by providing direct mapping onto against the selected components of certificates without the need to TCP/IP, simple protocol encoding, reduced number of operations, define a certificate component specific matching rule and without and string-based encoding of names and attribute values (hence of 37 4th Annual PKI R&D Workshop Pre-Proceedings requiring custom code to implement that matching rule for the cer- Certificate Certificate / CRL Registration Authority (CA) Repository (LDAP) Authority (RA) tificate attributes. Though the directory community saw GSER and component match- publish publish ing as an eloquent solution to the LDAP syntax and matching rule certificate certificate limitations, there were some concerns, as most LDAP server im- CRL plementations were not ASN.1 aware, that its adoption would be slow. To fulfill immediate needs of PKI applications, another solu- tion based upon attribute extraction (or “data de-aggregation”) has Certificate / Management CRL Access been being utilized as a practical remedy. The attribute extraction Transactions Management method decomposes a certificate into individual components and Transactions stores them into separate, searchable attributes. Certificate Parsing Server (XPS) [2] automates the attribute extraction process. Al- though this approach has filled the interoperability gap between LDAP and PKI, it is considered to be not a workable solution for PKI applications (and certainly not a workable general solution to End Entities the component matching problem), because it introduced a number of security and management issues. Figure 1. The Architecture of Public Key Infrastructure. In the spring of 2004, IBM undertook an engineering effort to pro- vide ASN.1 awareness (with GSER, BER, DER support) and com- ponent matching functionality for the OpenLDAP Project’s Stand- 2 LDAP in PKI alone LDAP Daemon (slapd), the directory server component of OpenLDAP Software [26]. To our knowledge, this is the first imple- 2.1 LDAP Certificate Repository mentation of the component matching technology in a pure LDAP directory server (second to the View500 [29] directory server from X.509 certificates and CRLs are commonly distributed by the cer- eB2Bcom [8] which is X.500 based). This paper presents a detailed tificate repositories. LDAP directories are the most versatile mech- and comprehensive description of the design and implementation anism of implementing the certificate repositories. Figure 1 illus- of the LDAP component matching for improved PKI support, ex- trates the conceptual interoperation of four entities in PKI. In the tending our previous work [19] which had described component public key registration phase, an end entity sends its identity as well matching in the context of WS-Security [24]. Another contribution as its public key to a Registration Authority (RA). If the identity is of this paper is that it proposes key mechanisms to improve per- validated by the RA, the Certificate Authority (CA) will publish formance and interoperability – attribute / matching rule aliasing, the end entity’s certificate, storing it in the LDAP directory. Af- component indexing, and selective component caching. This paper ter that, the published certificate can be retrieved by any properly will also present a preliminary performance evaluation result which authenticated LDAP client. If the issued certificate is revoked by convinces us that the performance of component matching is on par any reason, the CA is responsible for revoking the certificate by with or better than those of the syntax specific parsing and attribute publishing CRLs to the LDAP directory. LDAP directories serve extraction approaches if the optimization mechanisms proposed in as the central place where the end entities not only can download this paper are used. This in fact provides a strong evidential answer certificates of others in order to send encrypted messages or verify to the debate in the PKI standardization community on whether the digital signatures but also can be informed of the latest certificate component matching technology can be implemented in LDAP di- revocation information by downloading CRLs. rectory servers timely and efficiently. This paper also discusses on the possibility of using the component matching for CRL in order to support on-line certificate status checking using LDAP. It also dis- 2.2 Deficiencies of LDAP Certificate Access cusses on the feasibility of using LDAP component matching for PKI in Web services security. An end entity should be able to send a request to the LDAP cer- tificate repository searching for a certificate having matched values This paper is organized as follows. Section 2 introduces the in- in specific components of the certificate. As a principle example, teroperation of LDAP and PKI and describes the deficiencies of when it wants to retrieve the certificate having a specific serial num- LDAP when it is used for PKI. Section 3 describes the component ber and issued by a specific CA, it will send an assertion against matching technology and its use in PKI enabling secure and flexible serialNumber and issuer components as specified in certificateEx- certificate access. It also discusses on the possibility of certificate actMatch of X.509 [14]. However, the need for matching is not validation against CRL using LDAP component matching. Section limited only to these two certificate components. An end entity may 4 introduces GSER (Generic String Encoding Rules) which facili- want to search for certificates which belong to a subject. It may also tates the ASN.1 awareness in LDAP when it represents the attribute want to restrict the scope of the search for the subject’s certificates and assertion values. In Section 5, we present the design and im- to those having a specific key usage, e.g. nonRepudiation, by using plementation of the ASN.1 awareness and the component matching the keyUsage certificate extension. Because LDAP stores attribute in the OpenLDAP directory server. Section 6 demonstrates the ap- and assertion values in LDAP-specific octet strings which do not plication of the component matching for PKI to the security of Web generally preserve structural information of the underlying ASN.1 services. Section 7 shows experimental results of our prototype types, however, it is far from trivial to provide this component level implementation of the LDAP component matching and proves that matching in a generic and flexible way. the component matching can be accomplished without any loss in performance. Section 8 concludes the paper. X.500 [15] satisfies this demand for component level matching by allowing matching to be defined at the ASN.1 layer. For instance, [14] defines certificateExactMatch and certificateMatch matching 38 4th Annual PKI R&D Workshop Pre-Proceedings DN: o=IBM,c=US DN: o=IBM,c=US (userCertificate:certificateExactMatch:=12345$o=IBM,c=US) (a) Syntax Specific Parsing. (&(x509SerialNumber=12345)(x509KeyUsage=010000000)) (b) Attribute Extraction. DN: x509Serial=12345,cn=John DN: cn=John Doe,o=IBM,c=US Doe,o=IBM,c=US (userCertificate:componentFilterMatch:= and:{ cn: John Doe x509Serial: 12345 item:{ uid: 54321 x509Issuer: o=IBM,c=US component "toBeSigned.subject", certificate: MF4… … rule distinguishedNameMatch, value "cn=John Doe,o=IBM,c=US" } (a) DIT. (b) DIT of Attribute Extraction. item:{ Figure 3. Example Directory Information Tree (DIT). component "toBeSigned.extension.*. extnValue.(2.5.29.15)", rule bitStringMatch, value ‘010000000’B } } 2.3.2 Attribute Extraction ) (c) Component Matching. To address these deficiencies, Klasen and Gietz [22] proposed an alternative solution, based on a practical workaround that PKI ad- Figure 2. Three LDAP Certificate Access Methods. ministrators have been using. A set of attributes are extracted from the certificate and stored as simple, searchable attribute together with the certificate in a newly created entry which is subordinate to the original one. For this purpose, they defined a set of 30 at- rules by specifying them in ASN.1 data type representations. The tributes [22] for the X.509 certificate. Matching is performed on use of ASN.1 specifications is beneficial in the following respects: the extracted attributes. The example DIT with extracted attributes 1) parsing and matching can be automatically accomplished from is illustrated in Figure 3. DIT (a) in Figure 3 consists of person en- the given ASN.1 type specification without providing ad-hoc rou- tries under the base o=IBM,c=US each of which contains a certificate tines; 2) simple but powerful matching rules are derivable from the attribute. After attributes are extracted, the person entry will have a strong expressive power of ASN.1, as exemplified in the use of OP- new subordinate entry whose DN (Distinguished Name) becomes TIOANL in certificateMatch; 3) new matching rules can be easily x509Serial=12345,cn=John Doe,o=IBM,c=US. The attribute extrac- provided by specifying them in ASN.1. tion mechanism not only makes the end entity’s view of a DIT dif- ferent from the CA’s who published the certificates but also doubles The rest of this section explains how the current workarounds try the number of entries at minimum. to provide solution to the above mentioned interoperability gap be- tween LDAP and PKI and introduces the component matching ap- With the attribute extraction mechanism, performing matching proach focusing on its advantages over the earlier workarounds. against components is identical to performing matching against at- tributes as depicted in Figure 2 (b). Although attribute extraction fa- cilitates matching against components of a complex attribute, it can be considered as a suboptimal approach in the following respects. 2.3 LDAP Certificate Access Methods First, matching is performed on the extracted attributes, not on the certificate itself. Because the contents of the extracted attributes are 2.3.1 Syntax Specific Parsing mutable, there is non-zero chance of returning a wrong certificate to a client if the extracted attributes were maliciously forged. It is A brute force approach to providing matching for arbitrary compo- strongly recommended for the client to verify the returned certifi- nents of a certificate against an assertion is to provide certificate- cate again to ensure strong security. In the server side, on the other syntax specific matching rules. For example, it is possible to hand, the server administrator must ensure the integrity of a cer- manually write a special matching routine that matches the cer- tificate and the corresponding extracted attributes in order to mini- tificate attribute against the assertion value consisting only of se- mize this security vulnerability. Second, when there are more than rialNumber and issuer to implement certificateExactMatch which, one certificates in a directory entry, one per key usage for example, in case of X.500 [15], is meant to be derived automatically from it is not possible to pinpoint and return the certificate having the its ASN.1 specification [14]. In OpenLDAP, certificateExactMatch matching component (i.e. key usage for example again) since the is implemented by using certificate decoding libraries provided by searched-for attribute is different from the to-be-returned attribute. OpenSSL [27]. Figure 2 (a) shows an example filter in which the The matched value control [4] does not solve this problem, because predetermined token ’$’ is used to separate the serial number 12345 an LDAP attribute is set of values, not sequence of values. There- and the issuer distinguished name o=IBM,c=US. The server can rec- fore, it is inevitable to transform the DIT structure in designing a ognize the serial number and issuer name by reading two strings certificate DIT to avoid the need for an additional searching step separated by ‘$’. The downside of this approach is obvious. It is in the client [3]. Third, the attribute extraction does not facilitate too costly to define syntax specific matching rules for all possible matching against a composite assertion value as in X.500. It is not components and their combinations. It is also difficult to cope with possible to support a flexible matching as in X.509 certificateMatch the extension mechanisms such as a certificate and CRL extensions. without making LDAP directory servers ASN.1 aware. 39 4th Annual PKI R&D Workshop Pre-Proceedings Certificate.toBeSigned :: = SEQUENCE { 2.3.3 Certificate Parsing Server version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, An automatic attribute extraction mechanism was recently pro- signature AlgorithmIdentifier, posed. The Certificate Parsing Server (XPS) designed by the Uni- issuer Name, versity of Salford [3] extends the OpenLDAP directory server in validity Validity, order to automatically extract and store the certificate components. subject Name, Although it can significantly relieve the PKI administrator’s burden, subjectPublickKeyInfo subjectPublicKeyInfo, it does not improve the attribute extraction mechanism not to suffer issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIOMAL subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL from the three disadvantages of described above. extensions [3] EXPLICIT Extensions OPTIONAL } 2.3.4 Component Matching GSER encodings Component matching is recently published in RFC 3687 [18] in an effort to provide a complete solution to the LDAP - PKI interoper- { version 2, ability problem. All attribute syntaxes of X.500 and LDAP are orig- serialNumber 12345 , inally described by ASN.1 type specifications [15, 10]. However, signature { algorithm 1.2.840.113549.1.14, parameters NULL}, LDAP uses LDAP specific encodings which does not generally pre- serves the structural information in the original ASN.1 type, instead issuer {{type o, value IBM},{type c, value US}}, of relying on an ASN.1 encodings. The component matching de- validity {notBefore {2004 01 13 18 59}, notAfter {2005 01 13 18 59} }, fines a generic way of enabling matching user selected components … of an attribute value by introducing a new notion of component as- sertion, component filter, and matching rules for components. With } component matching, it becomes possible to perform matching of Figure 4. Certificate ASN.1 Specification and GSER Encoding. an assertion value against a specific component of a composite at- tribute value. For example, infrastructure is provided to perform matching against an arbitrary component of an X.509 certificate, assertion value is a component filter. The search filter for compo- such as serialNumber, issuer, subject, and keyUsage. Technical de- nent matching consists of three parts. tails of the component matching will be explained in the following sections. Compared to the attribute extraction approach, component • Component Reference: specifies which component of the at- matching has the following advantages: tribute value will be matched against the assertion value. 1. It does not extract and store certificate components separate • Matching Rule: specifies which matching rule will be used to from the certificates themselves. Therefore, it does not in- perform matching on the values. crease storage requirements and does not open a potential to • Value: An assertion value in GSER. the compromised integrity between a certificate and its ex- tracted attributes. 3.2 Certificate Access 2. Matching is performed not on the extracted attributes’ con- tents but directly on the certificate’s content. It can return only Component matching, as introduced in Section 2.3.4, enables the matched certificate out of multiple certificates in a user’s matching of an assertion value against a specific component of a entry if it is used in conjunction with the matched values con- certificate such as serialNumber, issuer, subject, and keyUsage. If trol [4]. a client receives a reference to a certificate consisting of the name 3. It becomes convenient to provide a complex matching flexi- of the issuing CA and its serial number, the client has to search bly because matching between attribute and assertion values for the certificate having matching issuer and serialNumber com- is performed at the ASN.1 layer. ponents in a certificate repository. Alternatively, a client may want to retrieve communicating party’s certificates, not all of them, but only the ones for the non-repudiation purpose, by matching its dis- 3 Component Matching for PKI tinguished name and key usage against the subject and keyUsage components of the certificate. For instance, the client can make 3.1 Component Matching and Its Usage an LDAP search request having the search filter illustrated in Fig- ure 2 (c) to search for the certificates of cn=John Doe,o=IBM,c=US The attribute syntaxes of X.500 are defined in ASN.1 types. The that are arranged to be used for non-repudiation. The example com- type is structurally constructed from basic types to composite types ponent filter of Figure 2 (c) contains two component assertions, one just like C struct definition. Every field of an ASN.1 type is a com- for subject and the other for keyUsage. The component references ponent. Based on ASN.1 types, component matching [18] defines to these components begin with toBeSigned which is a sequence how to refer to a component within an attribute value and how to of certificate components to be digitally signed for immutability. match the referred component against an assertion value. Match- toBeSigned.serialNumber refers to the serialNumber component ing rules are defined for the ASN.1 basic and composite types. It of a certificate while toBeSigned.extension.*.extnValue.(2.5.29.15) also defines a new assertion and filter tailored for a component, or refers to any extension of keyUsage type. In the latter example, each field of the ASN.1 type. These definitions are based on ASN.1 (2.5.29.15) is the object identifier (OID) of the keyUsage extension. so that they can be applied to any complex syntax, as long as it is It is contained in OCTET STRING of the extnValue of any com- specified in ASN.1. ponents of extensions certificate component. In other words, the reference means identifying all keyUsage extension components. The search filter for component matching is a matching rule asser- tion [10] whose matching rule is componentFilterMatch and whose The component matching rule specifies which matching rules will 40 4th Annual PKI R&D Workshop Pre-Proceedings X.509 Certificate OpenLDAP Server (slapd) ASN.1 Specification Component Filter Processing Certificate Attribute Processing Component Matching Matching Component (Assertion) Rule Rule (Attribute) eSNACC Compiler 6 5 Component Component GSER GSER Decoder Decoder Extractor BER DER GSER Extractor Component Component Component Component Tree Extractor Decoder Encoder Certificate Module Assertion Value Reference Caching Caching Loading 3 Matching Rules Indexer Component Component Filter Filter 4 DER DER Decoder Decoder Internal ASN.1 Data Representation Parser Parser (GSER) (GSER) 2 LDAP Component Component Certificate Filter Search Request 1 Figure 5. Architecture of Component Matching in OpenLDAP. be used to perform matching a certificate’s component against fully revised to reduce the CRL download traffic which can degrade an assertion value. Either existing matching rules or newly de- the scalability of PKI significantly, it still requires the end entities fined matching rules can be used as the component matching rules. to store CRLs in its local storage in order to facilitate efficient and Matching rules for composite types can be provided by combining off-line operation. On the other hand, on-line certificate validation those of their subordinate types. allComponentsMatch implements protocols are also proposed in order to cope with the on-line end matching at the ASN.1 layer whereas derived matching rules can be entities which need more fresh information on certificate validity. defined to override it with specific syntaxes. Because the on-line end entities need not store the certificate status information in its storage, the on-line protocols also eliminate the RFC 3687 [18] defines which matching rules can be applied to requirement for the hefty local certificate storage. Online Certifi- each of the ASN.1 types. In the example component filter in Fig- cate Status Protocol (OCSP) [21] and Simple Certificate Validation ure 2 (c), distinguishedNameMatch is used for subject and bit- Protocol (SCVP) [9] are two examples of the on-line certificate val- StringMatch is used for keyUsage. The component assertion value idation protocols. is a GSER-encoded value asserted against the component selected by the component reference. In Figure 2 (c), the value cn=John We conceive that component matching enabled LDAP can also be Doe,o=IBM,c=US is the GSER encoded ASN.1 UTF8 STRING and used as an on-line certificate validation protocol. CRL is a se- the value ‘010000000’B is the GSER encoded ASN.1 BIT STRING quence of pairs of a revoked certificate’s serial number and revoked value. time [11]. In order to check status of the certificate, the client needs to make a component assertion against the serial number of the cer- The client sends a search request containing the component filter to tificate under scrutiny. Then, the LDAP server will perform compo- a component matching enabled LDAP directory server. In response, nent matching on the CRL against the assertion to find the asserted the client will be returned with those entries having the matching serial number in the CRL. This is possible with component match- certificate if there is any. After checking the authenticity and in- ing, since the LDAP server understands the structure of the CRL tegrity of the returned certificate, the client can extract the public and is able to compare specific components of the CRL against the key out of the certificate for further use. component assertion. In the attribute extraction approach, however, the serial numbers of all the elements of the revoked certificate list must be extracted as separate attributes which need to be stored 3.3 Certificate Revocation List (CRL) Access in the individual subordinate entries. This not only increases the amount of storage and increases the complexity of managing direc- Although certificates were valid at the time when they were issued, tory significantly, but also makes the server vulnerable to malicious CA must revoke certificates occasionally because the key pair for a attacks as explained in Section 2.3.4. certificate can be compromised or the binding between an identity and a certificate become invalid. As a result, a certificate should With component matching, the whole CRL does not necessarily be validated when it is used. Otherwise, the client might incur not have to be downloaded to the client and scanned by the client so only incomplete, but also insecure transactions. The CRL mecha- as to save the network bandwidth and the client’s computing power nism [11] provides a means of performing validation of certificates significantly. Especially for the clients which have limited com- against periodically published list of revoked certificates, or Cer- puting power and low bandwidth such as mobile devices, compo- tificate Revocation List (CRL). A CRL is periodically generated by nent matching will be very efficient solution for the client to access the CA and is made available through certificate repositories such PKI. Furthermore, an LDAP server already has been widely used as LDAP directories. Although the CRL mechanism has been care- 41 4th Annual PKI R&D Workshop Pre-Proceedings typedef struct Certificate { typedef typedef struct structslap_component_desc {{ typedef typedef structslap_component_desc slap_component_desc { ComponentDesc* comp_desc; typedefstruct function_ptr slap_component_desc slap_component_desc{{ encoder_function; struct function_ptr encoder_function; ComponentVersion* version; function_ptr function_ptr encoder_function; encoder_function; function_ptr function_ptr decoder_function; function_ptr encoder_function; decoder_function; ComponentCertificateSerialNumber serialNumber; function_ptr function_ptr decoder_function; decoder_function; function_ptr function_ptr extractor_function; function_ptr decoder_function; extractor_function; ComponentAlgorithmIdentifier* signature; function_ptr function_ptr extractor_function; extractor_function; function_ptr function_ptr matching_functino; function_ptr extractor_function; matching_functino; ComponentName* issuer; function_ptr function_ptr matching_functino; matching_functino; }}ComponentDesc; function_ptr matching_functino; ComponentValidity* validity; }ComponentDesc; }ComponentDesc; ComponentDesc; } ComponentDesc; ComponentName* subject; ComponentSubjectPublicKeyInfo* subjectPublicKeyInfo; ComponentUniqueIdentifier issuerUniqueIdentifier; ComponentUniqueIdentifier subjectUniqueIdentifier; ComponentExtensions* extensions; } ComponentCertificate; typedef ComponentInt typedef struct AlgorithmIdentifier { typedef struct Name { typedef struct SubjectPublicKeyInfo { ComponentCertificateSerialNumber; ComponentDesc* comp_desc; ComponentDesc* comp_desc; ComponentDesc* comp_desc; ComponentOid algorithm; enum NameChoiceId { ComponentAlgorithmIdentifier* algorithm; typedef struct Int { ComponentAnyDefinedBy parameters; NAME_RDNSEQUENCE ComponentBits subjectPublicKey; ComponentDesc* comp_desc; } ComponentAlgorithmIdentifier; } choiceId; } ComponentSubjectPublicKeyInfo; int value; union NameChoiceUnion { } ComponentInt; typedef ComponentAny ComponentRDNSequence* rdnSequence; typedef struct Bits { ComponentAnyDefinedBy; } a; ComponentDesc* comp_desc; } ComponentName; AsnBits value; typedef struct Oid { } ComponentBits; ComponentDesc* comp_desc; typedef ComponentList AsnOid value; ComponentRDNSequence; } ComponentOid; typedef struct List { ComponentDesc* comp_desc; AsnList comp_list; } ComponentOid; Figure 6. Certificate Component Tree. for distributing CRLs and certificates. Hence, if the server can per- Hence, GSER is an essential mechanism to ASN.1 awareness and form on-line validity checking over the CRL as well, it will be very component matching. practical and efficient alternative to OCSP which needs additional software, or an OCSP responder. Figure 4 shows the ASN.1 type specification of a toBeSigned and its GSER encodings. The certificate is SEQUENCE so that there In [6], we also propose to structure the internal representation of are curly braces at the beginning and at the end of its GSER encod- CRL as an authenticated data structure such as the Certificate Revo- ings. It has version, serialNumber, etc. as its components inside of cation Tree (CRT) [16] and the authenticated 2-3 tree [23]. Together SEQUENCE. Within the braces, there is version and 2, or its value, with the component matching, it makes certificate validation result followed by comma which separates the subsequent field encoding. from an LDAP server unforgeable while not requiring to have the GSER defines each basic type’s encoding and then combines them LDAP server as a trusted entity nor to sign every LDAP response structurally to a more complex one by using “{”, “,” and “}”. On on the fly as in OCSP. the other hand, a native LDAP encoding does not have any system- atic rule to construct the structure information of attribute value in it. 4 GSER (Generic String Encoding Rules) A native LDAP encoding does not represent structure of an ASN.1 type. Instead, it is either in octet string or in binary. With the LDAP 5 Component Matching Implementation in encoding, as a result, it is difficult to contain the structural informa- OpenLDAP tion of ASN.1 type in its representation. In order to solve this prob- lem, S. Legg [17] recently proposed GSER (Generic String Encod- The overall conceptual architecture of the component matching in ing Rules). Component matching uses GSER as its basic encoding the OpenLDAP slapd directory server is illustrated in Figure 5. for the component assertion value. GSER generates a human read- Given the ASN.1 specification of the X.509 certificate as an in- able UTF-8 character string encoding of a given ASN.1 specifica- put, the extended eSNACC ASN.1 compiler generates the slapd in- tion with predetermined set of characters to keep the structure such ternal data representation of the X.509 certificate and their encod- as ‘{’, ‘}’, and ‘,’. It defines UTF8 string encodings at the lowest ing / decoding routines. We extended the eSNACC ASN.1 com- level of the ASN.1 built-in types such as INTEGER, BOOLEAN, piler [7] to support GSER in addition to the originally supported and STRING types and then it builds up more complex ASN.1 types BER and DER [7]. It also generates component equality matching such as SEQUENCE and SET from the lowest level by using the rules, component extract functions, and component indexer func- characters. Thus, the structural information of an ASN.1 specifica- tions which will be discussed later in this section in detail. In or- tion is maintained in encodings so that it can be recovered in the der to facilitate the integration of the newly defined syntaxes with- decoding process easily. By using GSER to store attribute values out the need of rebuilding the slapd executable, the generated data instead of the native LDAP encoding, an LDAP server is capable structures and routines are built into a module which can be dynam- of identifying the structure of ASN.1 specification of the attribute. ically loaded into slapd. The overall flows of LDAP component Furthermore, the component filter itself is also encoded in GSER. search is explained as follows; 42 4th Annual PKI R&D Workshop Pre-Proceedings 1. On the client side, a search for components of X.509 certifi- New Matching Rule cate is initiated by the inclusion of the ComponentFilter in the Component Reference filter of the search request. A ComponentFilter consists of (userCertificate:componentFilterMatch ComponentAssertions each of which is in turn comprised of := not:item:{ component, rule, and value. component “toBeSigned.serialNumber”, rule integerMatch, 2. On the server side, whenever slapd detects that the search re- Component Filter value 12345 quest contains ComponentFilter, it parses the incoming com- } ponent filter to obtain assertion values and component refer- ) Component Assertion ences. The assertion values are also converted to the ASN.1 internal representation by the GSER decoder. Figure 7. Example Component Filter. 3. Retrieve the entry cache to see if the target certificate’s de- coded component tree is cached. If so, skip the following steps upto the step 6. 5.1.2 Internal Representation of ASN.1 Type 4. If it is not cached, by using an appropriate ASN.1 decoder, slapd decodes the certificate attribute into the component tree, A new data structure of slapd is needed to represent an attribute the ASN.1 internal representation, when loading the candi- value as its components because the original data structure for date entries containing certificate for matching. Because a attribute types does not contain the structural information of an certificate is DER encoded, DER decoder is used to construct ASN.1 type in its representation. Every field of an ASN.1 type a certificate’s component tree. is a component which is addressable by a component reference. In our implementation, the component data structure consists of two 5. The component reference is fed into the component extractor parts: one to store the value of the component; the other to store to obtain the component subtree which is referenced by com- a component descriptor which contains information on how to en- ponent reference out of the attribute component tree. code, decode, and match the values. 6. The assertion component and the extracted attribute compo- nent are then matched together by the matching rule corre- The data structure of a component appears as a tree which keeps sponding to the component which is generated also by the the structural information of the original ASN.1 specification using extended eSNACC compiler. Matching is performed at the nodes and arcs. Each component node of the tree not only has data abstract level using the internal ASN.1 data representation. values but also represents the structural information of the given ASN.1 specification by having links to subordinate nodes. In the The rest of the section provide detailed description of the compo- tree, any node can be referenced by a component reference in order nent matching in two steps. After first describing how to make to perform matching on the corresponding component. Hence, we the OpenLDAP directory server ASN.1 aware in detail, compo- need a function to traverse the tree and locate the referenced node. nent filter processing, aliasing, component indexing, and compo- The ASN.1 compiler also generates component extractor routines nent caching will be described. for this purpose. Figure 6 illustrates the component data structure for Certifi- cate.toBeSigned. For the convenience of illustration, only seri- alNumber, signature, issuer, and subjectPublicKeyInfo are shown with their component subtrees among ten components of Certifi- 5.1 ASN.1 Awareness cate.toBeSigned. Let’s look at subjectPublicKeyInfo in more de- tail. Its component data structure, ComponentSubjectPublicKey- 5.1.1 eSNACC Compiler Info, contains a pointer to its component descriptor and its own sub- ordinate components, algorithm and subjectPublicKey. Algorithm Figure 6 shows the internal data representation of the toBeSigned is represented by ComponentAlgorithmIdentifier and subjectPub- ASN.1 type along with the representations of some of its key com- licKey is of the ASN.1 BIT STRING type which is represented by ponents. The data structures for this ASN.1 data representation ComponentBits. Leaf nodes of the component tree, such as Compo- are automatically generated by the eSNACC compiler from the nentBits and ComponentInt, contain the values of the ASN.1 basic given ASN.1 specification of toBeSigned. The generated data struc- types. ture for the toBeSigned has data fields corresponding to compo- nents of the toBeSigned ASN.1 type. Once the internal data struc- ture for toBeSigned is instantiated, it can be converted to DER 5.1.3 Syntax and Matching Rules by DEnctoBeSigned() and back to the internal representation by DDectoBeSigned(). An attribute is described by an attribute type in LDAP. An attribute type contains two key fields which help to define the attribute as Component matching can be performed for any composite at- well as the rules that attribute must follow. The first field is syn- tributes which are encoded as one of the ASN.1 encoding rules. tax which defines the data format used by the attribute type. The In addition to the DER used for a certificate, we have implemented second field is matching rule which is used by an LDAP server a GSER backend in the extended eSNACC compiler. GSER can to compare an attribute value with an assertion value supplied by be used as an LDAP-specific encodings for newly defined attribute LDAP client search or compare operations. Attributes must include types. With GSER, string-based LDAP-specific encodings can the matching rules in their definition. At least, equality matching maintain the structure of their corresponding ASN.1 types. The as- rule should be supported for each attribute type. From the view- sertion values in the component filter are also represented in GSER point of an LDAP server, an ASN.1 specification defining a new and the extended eSNACC compiler is used to decode them into attribute type requires a new syntax and its matching rule to be their internal representations. defined. To fully automate the component matching in which the 43 4th Annual PKI R&D Workshop Pre-Proceedings Table 1. Attribute Aliasing Table. Alias Attribute Aliased Attribute Component Reference Matching Rule x509certificateSerialNumber userCertificate toBeSigned.serialNumber integerMatch x509certificateIssuer userCertificate toBeSigned.issuer distinguishedNameMatch composite attribute types are defined in ASN.1, we extended the Table 2. X509 Certificate Decoding Time. eSNACC compiler to generate the basic equality matching rule of a d2i X509() ASN.1 given ASN.1 type, or allComponentMatch matching rule specified OpenSSL Decoder in RFC 3687 [18]. allComponentMatch matching rule evaluates to Time (usec) 32.74 40.20 true only when the corresponding components of the assertion and the attribute values are the same. It can be implemented by per- forming matching from the topmost component which is identified Attribute alias registers a set of virtual attributes to an LDAP by the component reference recursively down to the subordinate server. The virtual attributes themselves find correspond- components. The generated matching function of each component ing matching rules and component references by looking up can be overridden by other matching functions through a matching an attribute alias table. The example attribute alias ta- rule refinement table. Therefore, it is possible that a syntax devel- ble is shown in Table 1. X509certificateSerialNumber at- oper can replace the compiler-generated matching functions with tribute is aliased to “userCertificate.toBeSigned.serialNumber” the existing matching functions of slapd which might be more de- with the integerMatch matching rule. Hence, the filter sirable. In order to support this refining mechanism, slapd checks “(x509certificateSerialNumber=12345)” is considered equivalent the refinement table whether it is overridden by looking up the ta- to “(userCertificate:ComponentFilter:=item:component userCer- ble, whenever a matching functions are executed. tificate.toBeSigned.serialNumber, rule caseExactMatch, value 12345)”. With the attribute aliasing, clients only have to form sim- ple assertions to utilize component matching. Matching rule alias 5.2 Component Matching works in a similar way. An alias matching rule is mapped into the corresponding component reference and matching rule. 5.2.1 Component Assertion and Filter RFC 3687 [17] defines a new component filter as the means of ref- 5.2.3 Component Indexing erencing a component of a composite attribute and as the means The maintenance of proper indices is critical to the search perfor- of representing an assertion value for a composite attribute types. mance in the Component Matching as much as in the conventional Component assertion is an assertion about presence or values of attribute matching. In slapd, the attribute indexing is performed by components within an ASN.1 value. It has a component refer- generating a hash key value of the attribute syntax, matching rule, ence to identify one component within an attribute value. Compo- and the attribute value and maintain the list of IDs of those entries nent filter is an expression of component assertion, which evaluates having the matching value in the set of attribute values of the in- to either TRUE, FALSE, or Undefined while performing match- dexed attribute. ing. Figure 7 illustrate the example component filter. The compo- nent reference or toBeSigned.serialNumber identifies one compo- The component indexing can be specified in the same way as the nent in the certificate attribute value. In the component reference, attribute indexing, except that the component reference is used to “.” means identifying one of components subordinate to the pre- specify which component of a composite attribute to be indexed. If ceding component. In the component assertion, rule is followed the referenced component is a basic ASN.1 type, the indexing pro- by an integerMatch matching rule [15] which will be used to com- cedure will be the same as the attribute indexing. The indices for pare the following assertion value with the referenced component the referenced component are accessed through a hashed value of of the attribute value. The routines required to support the com- the corresponding syntax, matching rule, and value in the index file ponent filter and the component assertion were hand-coded while for the referenced component of the composite attribute. In OpenL- the routines for the component assertion values are automatically DAP, the indexing of the composite component is centered on the generated from a given ASN.1 type. GSER encoding of the component value. The hash key of a com- ponent value is generated from its GSER encodings together with 5.2.2 Attribute / Matching Rule Aliasing its syntax and matching rule. For the SET and SET OF constructed types, it is required to canonicalize the order of the elements in To enable component matching, clients as well as servers need to the GSER encodings before generating the hashed key value. For support GSER and new component matching rules. However, the component reference of SET OF and SEQUENCE OF con- client side changes will be minimal if at all, because the component structed types, its is needed to union the indices for each value ele- filter can be specified by using the existing extensible matching rule ment of SET OF and SEQUENCE OF. mechanism of LDAPv3 and the component assertion value is rep- resented as the text centric GSER encoding rules. Especially, the 5.2.4 Component Caching clients that accept search filters as strings require no changes to uti- lize component matching other than filling in the necessary compo- Whenever a certificate is matched against an incoming component nent filter as the search filter. However, for those clients who have filter, it is repeatedly decoded into the internal representation from search filters hard coded in them, we propose an attribute aliasing DER. This requires non-negligible CPU cycles as presented in Ta- mechanism which maps a virtual attribute type to an attribute com- ble 2. ponent and a component matching rule and a matching rule aliasing mechanism which maps a virtual matching rule to a component as- In order to eliminate the repeated decoding overhead, we decided sertion. to cache certificates in their decoded form, i.e. in the component 44 4th Annual PKI R&D Workshop Pre-Proceedings 8fb2adb53a9056a511d356947cedeec0 o=IBM,c=US 0 (a) XER. { serialNumber "8fb2adb53a9056a511d356947cedeec0", issuer "o=IBM,c=US" , keyUsage ‘010000000’B } (b) GSER. Figure 8. Example GenericCertificateReference. tree structure explained in Section 5.1.2. In the OpenLDAP direc- directly accesses PKI; the other indirectly accesses it by using ser- tory server, the entry cache is provided to store frequently requested vice proxies such as XML Key Management System (XKMS) [30] entries to enable very low latency access [5]. We extended the cur- which provides clients with a simple-to-use interface to a PKI so as rent entry cache to store decoded certificates along with other at- to hide the complexities of the underlying infrastructure. tributes of the entry. We devised various caching policies for the entry cache. In early implementations, we decided to cache a de- In the X.509 token profile of WS-Security [25], it is defined that the coded certificate as a whole, along with its entry in the entry cache. following three types of token references can be used: The size of a certificate is 899Bytes and that of the corresponding component tree is 3KBytes. Caching all the decoded component 1. Reference to a Subject Key Identifier: value of certificate’s tree consumes more than three times as much memory compared to X.509SubjectKeyIdentifier. the base entry caching. To reduce the memory requirements, we de- 2. Reference to a Security Token: either an internal or an exter- vised an indexing based caching policy. Since it is a common prac- nal URI reference. tice to index those attributes that are likely to be asserted, caching only those indexed components is a very practical solution to re- 3. Reference to an Issuer and Serial Number: the certificate is- duce the memory requirement. In our experiment, the serial number suer and serial number. component was cached which takes only 148Bytes of memory. Because it is defined as extensible, any security token can also be used based on schemas. It is shown in Figure 8 that the 6 Component Matching in WS-Security element of is used as the security token. defined in [31] contains various references SOAP (Simple Object Access Protocol) is a protocol for invoking such as X509IssuerSerial, X509SubjectName, X509SKI, and so on. methods on servers, services, components, and objects [1]. It is a With the ASN.1 awareness and the component matching support in way to create widely distributed, complex computing environments the OpenLDAP directory server, these references can be used with- that run over the Internet using existing Internet infrastructure, en- out the need of implementing syntax specific matching rules for abling Web service developers to build Web services by linking het- various types of references. It is also possible in erogeneous components over the Internet. For interpretability over to use elements from external namespace for further flexibility. heterogeneous platforms, it is built on top of XML and HTTP which are universally supported in most services. WS-Security is recently Figure 8 shows one such example. Here, GenericCertificateRefer- published as the standard for secure Web Services [24]. It provides ence element from dsext namespace is used to provide a generic a set of mechanisms to help Web Services exchange secure SOAP reference mechanism which implements CertificateMatch in the message. WS-Security provides a general purpose mechanism for X.509 recommendation [14]. The reference consists of a sequence signing and encrypting parts of a SOAP messages for authenticity of certificate attributes, serialNumber, issuer, subjectKeyIdentifier, and confidentiality. It also provides a mechanism to associate se- authorityKeyIdentifier, certificateValid, privateKeyValid, subject- curity tokens with the SOAP messages to be secured. The security PublicKeyAlgID, keyUsage, subjectAltName, policy, pathToName token can be cryptographically endorsed by a security authority. each of which is defined optional. By using the example reference, It can be either embedded in the SOAP message or acquired ex- it would be possible to perform security key reference in a very ternally. There are two types of PKI clients in WS-Security: one flexible way. It would be possible to search for a certificate having 45 4th Annual PKI R&D Workshop Pre-Proceedings 20K 4K 18K CM CM OpenSSL 16K OpenSSL XPS 3K XPS 14K 12K op/sec op/sec 10K 2K 8K 6K 1K 4K 2K 0K 0K 1 4 8 15 20 1 4 8 15 20 # of Clients # of Clients (a) 100K Entries (No Memory Pressure). (b) 500K Entries (High Memory Pressure). Figure 9. The Performance of Three Approaches. a subjectAltName with a specific keyUsage. Figure 8(a) shows that In the experiment, OpenLDAP stand-alone directory server, slapd, the reference is encoded in XML while Figure 8 (b) shows that the was used as an LDAP certificate repository testbed for all three reference is encoded in GSER. methods. Slapd as of OpenLDAP version 2.2.22 supports both the component matching and the certificate specific matching. The at- With the component matching enabled LDAP server, the GSER en- tribute extraction mechanism was tested by using the XPS patch to coded reference value can be used as an LDAP assertion value in OpenLDAP which was contributed to the OpenLDAP project by a component filter. With the ASN.1 awareness support, the LDAP University of Salford. XPS was used to automatically generate the server is now capable of understanding the structure of the Certifi- DIT for the attribute extraction. The same version of slapd was cateAssertion type when configured with its ASN.1 definition. Be- tested for all three mechanisms for the LDAP certificate repository. cause encoders / decoders for various encoding rules (GSER, DER, XER ...) are automatically generated and integrated into the LDAP Fgure 9 (a) shows the throughput of three approaches, varying the server, it is possible to use ASN.1 values encoded in those encoding number of clients. With 100k entries, the peak throughput of com- rules as an assertion value in an LDAP search operation. ponent matching and attribute extraction mechanisms are almost the same. The certificate-syntax specific matching (OpenSSL decoder) With the ASN.1 aware and component matching enabled LDAP exhibits slightly lower performance than the other two methods. We server, flexible reference formats for X.509 certificates can now be attribute the reason of lower throughput to longer code path of slapd defined in ASN.1 to configure the LDAP server to understand the such as normalization and sanity checks of assertion values when it reference. The required matching rules, encoders, and decoders for uses the OpenSSL library. In order to observe the behavior of the the reference type will be automatically generated and integrated to three methods in the presence of memory pressure, we increased the the LDAP server. This increased flexibility will foster the flexible number of entries to 500K and the database cache size is reduced use of security token references in the LDAP server by making it from 1GB to 200MB. With this configuration, only small portion easy to create and update references. of the entries can be cached and hence the system suffers from fre- quent memory swapping. Figure 9 (b) shows that the throughput of all three methods are degraded significantly compared to Figure 9 7 Experimental Results (a). The peak throughput of component matching is 3250 ops/sec, significantly degraded from 17,057 ops/sec with no memory con- We used MindCraft’s DirectoryMark [20] tools to generate the di- straint. The attribute extraction mechanism is hit by even further rectory entries and client scripts containing a list of LDAP opera- performance degradation than the other two mechanisms. This is tions. The client scripts were run on an 8-way IBM xSeries 445 because the number of entries becomes doubled by extracting at- server with Intel Xeon 2.8GHz processors and the directory server tributes and by having them as separate entries subordinate to the was run on an IBM xSeries 445 server with 4 Intel Xeon 2.8Ghz original ones. This results confirms that the component matching is processors and with 12GB of main memory running SUSE SLES9 a superior approach to the attribute extraction with respect to per- (Linux kernel version 2.6.5). We used the transactional backend formance as well as to security and manageability. (back-bdb) of OpenLDAP version 2.2.22 together with Berkeley DB 4.3 and OpenSSL 0.9.7 for the evaluation. Two different size DITs with 100K and 500K entries were used for evaluation. Our in- 8 Conclusion tension of using two different size DITs was to observe the through- put of slapd with and without memory pressure. With 100k entries, Although it is a general consensus in the PKI standardization work- all the entries was able to be cached into the DB cache. On the other ing group that the component matching is a complete solution to hand, with 500k entries, we observed that the server experienced a the LDAP - PKI interoperability problem, it was under debate that number of memory swapping and disk I/O due to memory shortage. its adoption in LDAP servers might be slow and an alternative so- The directory was indexed for cn, sn, email of inetOrgPerson and lution needed be pursued in the interim. In this paper, we have pre- for serialNumber and issuer of userCertificate (or the corresponding sented the design and implementation of the component matching extracted attributes in the case of attribute extraction mechanism). in OpenLDAP slapd. Our work provided a strong evidence that the 46 4th Annual PKI R&D Workshop Pre-Proceedings component matching can be implemented in pure LDAP-based di- [13] ITU-T Rec. X.680, Abstract syntax notation one (ASN.1): rectory servers without exploding complexity and degrading perfor- Specification of basic notation, December 1997. mance. Our work also proposed a number of enhancements to the [14] ITU-T Rec. X.509, The directory: Public-key and attribute component matching technology to improve performance and inter- certificate frameworks, March 2000. operability with legacy clients. In this paper, we also proposed the use of the component matching enabled LDAP as a secure on-line [15] ITU-T Rec. X.500, The directory: Overview of concepts, certificate validation protocol. We further demonstrated the useful- models and service, February 2001. ness of the component matching in WS-Security as a key applica- [16] P. C. Kocher. On certificate revocation and validation. In tion. As PKIs are being adopted in larger scale and in more critical Proc. of the 2nd Int’l Conference on Financial Cryptography deployments, it becomes more important to provide as complete (Lecture Notes in Computer Science, Vol. 1465), pages 172– a solution as possible, especially when it comes to security. The 177, 1998. component matching technology enables more secure and flexible implementation of LDAP certificate repositories for PKI without [17] S. Legg. Generic string encoding rules. RFC 3641, October compromising performance. 2003. [18] S. Legg. X.500 and LDAP component matching rules. RFC 9 Availability 3687, February 2004. [19] S. S. Lim, J. H. Choi, and K. D. Zeilenga. Secure and flexible The component matching software is included in OpenLDAP certificate access in WS-Security through LDAP component release as a module and can be downloaded at http://www. matching. In ACM Workshop on Secure Web Services held in openldap.org/software/download/. The eSNACC ASN.1 conjunction with the 11th ACM Conference on Computer and compiler can be obtained from DigitalNet at http://digitalnet. Communications Security, October 2004. com/knowledge/download.htm. [20] Mindcraft. DirectoryMark. http://www.mindcraft.com/ directorymark/. 10 References [21] M. Myers, R. Ankney, A. Malpani, and C. Adams. Internet X.509 public key infrastructure online certificate status proto- [1] D. Box and D. Ehne. Simple object access protocol (SOAP). col - OCSP. RFC 2560, June 1999. W3C Note, May 2000. [22] N. Klasen and P. Gietz. Internet X.509 public key infrastruc- [2] D. W. Chadwick. Deficiencies in LDAP when used to support ture lightweight directory access protocol schema for X.509 PKI. Comm. of the ACM, 46(3), March 2003. certificates, , October 2004. LDAP to support X.509-based PKIs. In 17th Annual IFIP [23] M. Naor and K. Nissim. Certificate revocation and certifi- WG 11.3 Working Conference on Database and Applications cate update. In Proc. of the 7th USENIX Security Symposium, Security, August 2003. pages 217–228, January 1998. [4] D. W. Chadwick and S. Mullan. Returning matched values [24] OASIS. Web services security: SOAP message security 1.0 with LDAPv3. RFC 3876, September 2004. (WS-Security 2004). OASIS Standard 200401, March 2004. [5] J. H. Choi, H. Franke, and K. D. Zeilenga. Performance of the [25] OASIS. Web services security: X.509 certificate token profile. OpenLDAP directory server with multiple caching. In Pro- OASIS Standard 200401, January 2004. ceedings of International Symposium on Performance Eval- uation of Computers and Telecommunication Systems, July [26] OpenLDAP. http://www.openldap.org. 2003. [27] OpenSSL. http://www.openssl.org. [6] J. H. Choi, S. S. Lim, and K. D. Zeilenga. On-line certificate [28] The Unicode Consortium. The Unicode Standard, Version 4.0. revocation via LDAP component matching. To be presented Addison-Wesley, Boston, 2003. in DIMACS Workshop on Security of Web Services and E- Commerce, May 2005. [29] View500. http://www.view500.com. [7] DigitalNet. Enhanced SNACC ASN.1 software. http:// [30] W3C. XML key management specification (XKMS). W3C www.digitalnet.com/knowledge/snacc_home.htm. Standard, March 2001. [8] eB2Bcom. http://www.e2b2com.com. [31] W3C. XML - signature syntax and processing. W3C Stan- dard, February 2002. [9] T. Freeman, R. Housley, A. Malpani, D. Cooper, and T. Polk. Simple certificate validation protocol (SCVP). [32] F. Yergeau. UTF-8, a transformation format of ISO 10646. , Feburuary 2005. RFC 3629, November 2003. [10] J. Hodges, R. Morgan, and M. Wahl. Lightweight directory access protocol (v3): Technical specification. RFC 3377, September 2002. [11] R. Housley, W. Ford, W. Polk, and D. Solo. Internet X.509 public key infrastructure certificate and CRL profile. RFC 2459, January 1999. [12] ITU-T Rec. X.690, ASN.1 encoding rules: Specification of basic encoding rules (BER), canonical encoding rules (CER), and distinguished encoding rules (DER), 1994. 47 4th Annual PKI R&D Workshop Pre-Proceedings PKI without Revocation Checking Karl Scheibelhofer Institute for Applied Information Processing and Communications Graz University of Technology, Inffeldgasse 16a, 8010 Graz, Austria Email: karl.scheibelhofer@iaik.tugraz.at than a second. Certificate based PKIs have Abstract been designed based on the assumption that Current X.509-based PKIs are typically network connectivity is a limited and expen- complex. One of the most critical parts is sive resource (see III in [13]). revocation checking. Providing revocation information is a big effort for CAs, and for This paper considers current certificate clients it is even more costly to get all re- and revocation checking practice in the light quired revocation data. This work provides of ubiquitous access to the Internet. The a performance calculation of two CA setups focus is on X.509 certificates [1] and current with CRLs, delta CRLs and OCSP as revo- revocation checking techniques like CRLs cation checking mechanism. The enhance- and OCSP [2]. Based on this analysis, we ment of this work is the proposal to avoid propose a simple way to make certificate revocation checking by issuing certificates handling and validation easier in a net- on-line and only retroactively. An analysis worked environment. The proposed ap- shows that this approach performs at least proach is an on-line certification service. as good as OCSP and much better than The CA issues a new certificate each time CRLs. In addition, this solution reduces the the key owner uses the key. We will show complexity of PKI significantly. that this requires not more effort than OCSP, neither on the CA side nor on the client side. Moreover, it reduces the overall complexity Introduction of the system and provides up-to-date status Today, most computers are connected to information about the key. This can be seen a network. Usually, this is a corporate net- as a special version of short-lived certifi- work, a home network or a campus network, cates, which have been proposed several and this network is commonly connected to times (e.g. [9]). Unlike short-lived certifi- the Internet through firewalls and routers. cates, here, the validity time degrades to an Pure off-line systems are the exception instant in time which lies in the past. Thus, rather than the rule nowadays. Even if many the statement made by the CA through a computers are only on-line from time to certificate can be definitive, which makes time, they attach to a network on a regular revocation a less critical issue in many basis. This holds for notebooks, PDAs and cases. There is no need for revocation smart phones. However, with most of these checking of such certificates; the certificate devices, it is easy to go on-line. The Internet already contains the status information. becomes ubiquitous: Ethernet at the office, cable modem or DSL at home, WLAN at Certificate Validity campus, airports and rail stations, 3G in cit- ies and more to come. Network connectivity Each X.509 certificate contains a validity is no scarce resource any longer, as well as period, which is a time interval determined performance. Even smart phones can create by a start date and an end date. The start date and verify digital signatures in much less is normally the time at which the CA issued 48 4th Annual PKI R&D Workshop Pre-Proceedings the certificate. The end time is often calcu- cial extension to its response messages, the lated as a fixed offset from the start time, archive cutoff extension. Thus, OCSP re- e.g. start time plus one year. One year is a sponders may extend the period through typical validity frame for a public-key cer- which status information about certificates is tificate. The certificate validity is often in- available. However, it does not really extend terpreted as "this certificate is valid during the validity period in the sense defined by this time interval unless it is revoked". How- PKIX because in practice, a certificate ever, PKIX [1] defines it differently: The owner cannot revoke a certificate which has certificate validity period is the time interval already expired. In consequence, relying during which the CA warrants that it will parties can get information about revocation maintain information about the status of the issues which happened within the certifi- certificate. On the first look, the two inter- cate's validity period, but they cannot get pretations seem to be similar, but there are revocation issues beyond this period. The subtle differences. The PKIX definition does CA does not offer such service for expired not imply any validity information. A cer- certificates. tificate can still be valid even beyond its validity period. The CA simply does not Revocation Checking guarantee to provide information about the In general, a certificate which is within its validity of this certificate outside this time validity period can be valid or revoked. A frame. The first interpretation does not ac- client cannot find out the status of the cer- cept a certificate which has been used out- tificate off-line. Finding out if a certificate is side its validity period, no matter, if other valid requires access to some network re- status information is available. In practice, source. This can be the current CRL on a the application of both interpretations ends web server or an OCSP responder. in the same results. The reason is that most CAs do not provide positive status informa- CRLs tion for certificates. This means, the CA tells clients what certificates are definitely re- CRLs are a problematic mechanism for voked, but only for certificates which are revocation checking. For the CAs they pro- within their validity period. For other certifi- vide a simple means with low requirements cates, the clients do not get any revocation concerning signature creation and security. information. If a certificate runs out of its For the relying parties who need to verify validity period, we call it expired. In case a certificates, CRLs are a pain. They are often considered certificate expired, clients have quite large, they often contain close to 100% no means to find out if the CA no longer irrelevant information and they usually pro- provides revocation information or if the vide no current revocation information. certificate has not been revoked. In other Consider SSL [4] server certificates from words, a client may or may not find out if an Verisign, Inc.. They contain a CRL distribu- expired certificate has been revoked before tion point referring to the location of the it expired. The client has no guarantee that current CRL. However, this CRL is about such certificates are listed on the CRL. 750 kByte. In consequence, most browsers work without revocation checking for server The situation is similar for OCSP. Since certificates. Downloading the CRL would OCSP responders may cache old CRLs, they take considerable time and would delay the may provide certificate revocation status HTTP transfer unacceptably long. beyond certificate expiration. A responder can indicate such support by adding a spe- 49 4th Annual PKI R&D Workshop Pre-Proceedings CRLs have a validity period similar to the server could be replaced by a backup certificates. It is determined by the time at system. In case of a key compromise, how- which the CRL has been issued, called thi- ever, the administrator would need to revoke sUpdate, and the time at which the next the certificate immediately and inform all CRL will be issued latest, called nextUp- clients quickly. A delay of several days ap- date. According to PKIX, a client can cache pears intolerable. CRLs do not provide an a CRL until nextUpdate and rely on this efficient solution in this situation. Reducing information. However, it is apparent that a the caching time of CRLs does not offer a CRL cannot provide status information significant improvement either. The client newer than indicated in its thisUpdate field. may download the latest CRL for each cer- Caching the CRL is nice and provides a tificate validation issue, but this is impracti- benefit in some special applications, but for cal. It wastes bandwidth and introduces de- many applications, it does not make much lays, which are unacceptable for many ap- sense. System designers using cached CRLs plications. Moreover, the server which pro- should be aware of the fact that relying on vides the CRL would break down under the cached CRLs may produce load if all clients would download the cur- non-deterministic behavior for revocation rent CRL every time, at least in environ- checking. Consider a web server certificate. ments with a considerable number of certifi- The mentioned CRL has a validity period of cates and entries in the CRL. The waste of two weeks. Thus, in case of certificate revo- bandwidth in such configurations would be cation, clients will notice this revocation up enormous. to two weeks later and one week later on average if they cache the CRL as long as Almost all data in a CRL is of no interest possible. Until the cached CRL expires, the for the client. This is easy to see. The client client will consider the certificate as not re- is usually only interested in the status of a voked, even if it has already been revoked. single certificate. The CRL returns a list of This information simply did not yet propa- all revoked certificates in which the client gate to the client because the cached CRL can look up the concerned certificate. In has been used. Thus, the client will get a most cases, the certificate of interest will not different result for revocation checking the be listed in the CRL. Revocation is more an same certificate twice, even if checked with exceptional case than a common case. respect to the same time. This Common rates for certificate revocation are non-deterministic behavior can be a 5 to 10 percent, i.e. about 5 to 10 percent of show-stopper for certain applications; for all issued certificates get revoked before instance consider applications where relying they expire. This would mean that a client parties transfer noticeable volumes of money would find the certificate of interest on the based on a positive signature verification CRL in at most 1 of 10 (10 percent) or 1 of (including a certificate validation with revo- 20 (5 percent) cases. At most because a re- cation checking). voked signature or authentication certificate will typically only be used after revocation Usually, administrators would switch to a in case of a key compromise. If the certifi- new certificate even before they revoke the cate owner loses the private key, the certifi- old certificate. As long as there has not been cate is useless and cannot be used any a key-compromise, revocations may not be longer. Likewise, the legitimate owner that critical anyway. These cases can often would not use a certificate which has been be handled by organizational means. For revoked because of changed owner informa- example, the certificate can be updated, or tion. Key compromise will naturally be a 50 4th Annual PKI R&D Workshop Pre-Proceedings scarce reason for revocation compared to - The issuer of the CRL could be different key-loss and change of subject information. to the issuer of the certificate. It may be As a result, a CRL will contain the con- difficult to make a trust decision and no cerned certificate even less frequently as user wants to do this manually (most us- calculated before. In effect, during a single ers do not even have the required back- certificate validation procedure, a CRL car- ground knowledge to do it). ries only a single bit of information for the client. The client wants to know if the con- - If the application has to verify a certifi- sidered certificate is valid (or was valid at a cate (which may already be expired) certain time). The answer can only be yes or with respect to a time in the past, it no (unknown can be considered as a third would need an old CRL. There is no alternative). Compared to such large CRLs standardized way to get an old CRL. The as mentioned before, which contain over standards only specify how to get the lat- 20000 entries, the waste of resources be- est CRL. comes obvious. This list can be extended by various bul- The PKIX standards also define so-called lets. These cases do not frequently appear in Delta CRLs. Their main goal is to reduce practice, but they are perfectly valid accord- bandwidth demand. Subsequent CRLs differ ing to the underlying standards. If a devel- only slightly in their contents compared to oper has to implement a system, which sup- their predecessor. Some new entries are ports this standard, the system needs to be added and some old may be removed, but able to handle these special cases as well, the vast majority of the entries will stay the even though they might never appear in same between two subsequently issued practice. As a result, developers may end up CRLs. Thus, the idea is to transfer only with a final system where many parts of the changes in the CRL most of the time. A certificate validation system are never really delta CRL refers to a complete CRL and just used. mentions the differences to this CRL, i.e. the added entries and the removed entries. Thus, For completeness, we should mention the client has the same information as if it that there are use-cases where CRLs are suf- would have two complete CRLs. Delta ficient and the required bandwidth is not that CRLs are rarely used in practice. The added critical. If the CRL does not contain many complexity is one of the reasons. entries, the lavished bandwidth is not that significant either. The size of the CRL can Revocation checking does only look that be decreased using different approaches. A simple on the first look. If one implements simple one is to use partitioned CRLs. Using the complete PKIX specification and con- this method, the CA splits the set of all is- siders all (or at least all practical) use-cases, sued certificates into groups of similar size. revocation checking based on CRLs can get The CA will issue an individual CRL for complex. Here are some reasons: each group of certificates. Thus, the certifi- cates, even though issued by the same CA, - There could be a different CRL for each will point to a different CRL location, de- revocation reason. In consequence, the pending on the group they belong to. For client would have to check each of these CAs which issue only a small number of CRLs. certificates, the CRL will generally stay small enough without segmentation. 51 4th Annual PKI R&D Workshop Pre-Proceedings OCSP This is nice for OCSP service providers be- CRLs have been designed as an off-line cause it allows very simple implementations mechanism for revocation checking. An of an OCSP responder. In this case, the off-line mechanism cannot meet certain re- OCSP service is nothing more than a quirements for timeliness and efficiency. So front-end for the latest CRL. Consequently, what about on-line protocols? Does OCSP an OCSP service implemented this way in- perform better? It may. At least, it does not herits the problems inherent to CRLs except waste that much bandwidth in most cases. the bandwidth consumption. Remarkably, the bandwidth consumption of CRLs is the The basic idea of OCSP is simple. It is an biggest cost factor for big CAs as docu- on-line service which provides revocation mented in [11]. information about certificates to clients. When the client needs to validate a certifi- Revocation Checking in cate, it can send a request to an OCSP re- Practice sponder. The OCSP server answers with In practice, many systems do not perform information about the revocation state of the revocation checking at all. This has various certificate. Unfortunately, there are some reasons. Most web browsers do not check details which can make OCSP harder to use server certificates for revocation. The main than necessary. First, the client needs the reason seems to be the potentially long delay issuer certificate of the certificate of interest due to downloading the CRL. Many email because the hash of the issuer certificate's clients often perform no checking per de- public key is required in the OCSP request fault either. The long delay seems to be the message. Second, the response of the server reason once again. However, most applica- may not be as concrete as the client would tions at least offer options to enable revoca- need it to be. A normal OCSP response does tion checking. Some of them, for instance not provide positive certificate status infor- Microsoft Outlook 2002 or later, perform mation. OCSP responses have several prop- revocation checking per default. It is easy to erties which degrades their effectiveness in identify such email clients with enabled many use-cases: revocation checking because there often is a long delay if the user opens a signed or en- - The response does not say if the certifi- crypted email. Downloading the CRL takes cate is valid, it merely says that the cer- most of this time. tificate is not revoked. However, this can even mean that the certificate has never Only a few systems support OCSP. been issued.1 Mozilla is one of these few exceptions. Most web browsers and email clients do not sup- - The revocation information provided by port it, at least not without additional an OCSP server may not be up to date. third-party tools. On the CA side, the situa- tion is similar—not many of them run OCSP At a minimum, a client cannot expect to servers. Those who run an OCSP server of- get more information from an OCSP re- ten implement them based on CRLs rather sponder, as it can get from the latest CRL. than to base them on current status informa- tion. Third-party OCSP responders usually 1 The German ISIS-MTT [12] profile defines the have no other means than to base their re- CertHash extension for OCSP responses. A response sponse information on CRLs. Third-party containing this extension can provide a positive status OCSP responders have the advantage that information. 52 4th Annual PKI R&D Workshop Pre-Proceedings they can provide revocation information for unless the CRL is very small which is typi- certificates from various CAs. On the other cally not the case. Verifying the signature of hand, users must configure their clients the status information—the signature on the manually to use external responders. In sen- CRL or on the OCSP response—is effec- sitive environments, it might be impossible tively the same effort for the client. The to rely on another external party; additional timeliness of the status information may also contracts have to be prepared, liability issues differ between CRLs and OCSP. An OCSP have to be clarified, and so on. responder may provide real-time revocation information, while a CRL always provides OCSP is capable of providing a better aged information, though, many OCSP serv- service to clients than CRLs can do. For the ers do not provide more current information provider side, OCSP requires additional re- than the CRLs do. sources. Since OCSP is an on-line service, it requires a reliable server system with a high Small CA Big CA level of security. The server has to sign its Certificates 1 000 1 000 000 responses with a private key. This key re- Certificate Users 1 000 1 000 000 Certificate Validity 1 1 quires the same security level as the key for [years] CRL signing does because it serves to pro- Revocation 10% 10% tect the same kind of information— Probability revocation information for the same certifi- Certificate 10 10 cates. Some simple investigations and calcu- Validations per lations show that OCSP shifts the demands Certificate [day-1] from network bandwidth to processing Table 1: Properties of the considered configura- power. tions Calculations can show some values for Table 1 shows the properties of two CA the performance estimation of CRLs and configurations which we will use as a basis OCSP for revocation checking. First, we for performance estimations. There are two sketch rough values for the required band- configurations—a small CA configuration width in certain environments. In addition, with thousand issued certificates, and a big we consider the number of required signa- CA with one million issued certificates. We ture creations on the server, which differs set the validity period of the issued certifi- significantly between CRLs and OCSP. On cates to one year, which is a typical value. In the client side, CRLs and OCSP have also addition, we assume that the number of cer- others impacts. If a client uses CRLs, it tificate users (users who validate certificates needs to cache CRLs. Without caching, from this CA) is roughly the same as the CRLs are a real performance and resource number of issued certificates. However, killer because the client would download the these two numbers can vary significantly in complete CRL for each revocation checking. practice; a CA issuing only server certifi- Some implementations do this intentionally cates for a few big web servers like Amazon, to ensure that they have the latest available eBay and Google would have a huge number revocation information. This practice cannot of users validating the certificates while the be recommended in general. If there is a number of issued certificates is small. For demand to get always the latest revocation the probability of certificate revocation, we information, OCSP is a better choice. In take 10%, i.e. the probability that a certifi- addition, processing a CRL is usually more cate will be revoked before it expires. This is costly than processing an OCSP response, 53 4th Annual PKI R&D Workshop Pre-Proceedings also a quite common value in practice, but it name. For this additional data, we assumed may even be much lower, e.g. one percent. 250 Byte. If we take the small CA, for ex- We assume, that a user validates about 10 ample, the CRL would contain 50 entries on certificates per day, for example, verify 5 average3, which will result in a size of 2250 signed emails and encrypt 5 emails per day. Byte (50.40 + 250). The total number of These numbers set the frame for our short certificates and the probability of certificate investigations. They are typical values, even revocation determine the number of entries. though there are configurations for which Taking the 10 certificate revocation checks these values would look very dissimilar and per user and per day, every user downloads would result in quite different performance each issued CRL. This ends up in a network estimations. transfer volume of 2,1 MB per day for the small CA and 1900 GB per day (about 22 Small CA Big CA MB per second) for the big CA. This is a CRL Validity 24 24 noteworthy volume. Only big companies can [hours] afford such a network bandwidth, and often Signature 4 3 014 merely in a local network and hardly via the Creations [day-1] Internet. It is also a matter of costs. Would CRL Size [Byte] 2 250 2 000 250 CRL Downloads 1 000 1 000 000 you afford this for revocation checking only [day-1] if there are cheaper alternatives? Bandwidth 2,1 1 900 000 [MB/day] Moreover, these numbers can easily in- Table 2: Expected CRL Performance crease. The current numbers are based on an issuing interval of one day. In the worst Table 2 shows the expected performance case, clients get one-day-old revocation in- data for the two CAs using CRLs for revoca- formation. If the managers of a system de- tion checking. We took a CRL validity of 24 cide to increase the CRL issuing frequency hours. This is the time between the thisUp- to get a better timeliness, the increase of date and nextUpdate values in the CRL. The network transfer is inverse proportional. number of signature creations required on Reducing the CRL validity to the half (i.e. to the CA side is comprised of certificate and 12 hours) doubles the transfer volume. The CRL issuing—one signature per each cer- peaks of bandwidth consumption may be tificate and each CRL. For instance, the even much higher because we assumed small CA issues 3 certificates per day on evenly distributed download requests over average and 1 CRL, which requires 4 signa- time. In practice, peaks are very likely, for ture creations in total per day. Here, the cer- instance, in the morning when people start tificates account for most of these signatures working there will be a peak, while the because the CA issues CRLs infrequently. download rate will drop during the night. For calculating the CRL size, we took 40 Byte as the size of each CRL entry2. Despite the entries of the revoked certificates, each CRL contains additional data like the signa- ture, thisUpdate, nextUpdate and the signer 3 We get 100 entries in the worst case, which occurs 2 This consists of at least 13 Byte for the revocation if the CA issues all certificates at the same time (e.g. date, plus the serial number (e.g. a SHA-1 hash at the beginning of the year). If it issues the certifi- value), plus an overhead for the DER encoding of at cates continuously over the year, we could expect 50 least 6 Byte. In addition, there may be extensions for entries in each CRL, because on average a certificate the reason code or invalidity date. would be revoked after half of its validity period. 54 4th Annual PKI R&D Workshop Pre-Proceedings delta CRL signatures are required addition- Small CA Big CA ally, while the number of signatures for base Base CRL 7 7 7 7 CRLs decreases at the same time because Validity the CA issues them only once a week. [days] Delta CRL 24 2 24 2 Validity As a result, we can see that the bandwidth [hours] consumption decreased significantly. In the Signature 4 15 3015 3025 case where delta CRLs are issued once a Creations day—which provides the same timeliness as [day-1] the full CRL case considered before—the Base CRL 2250 2250 2000250 2000250 transferred data volume dropped to 0,58 MB Size [Byte] Avrg. Delta 288 288 38606 38606 per day for the small CA and to 310 GB per CRL Size day for the big CA. This is a reduction of [Byte] about 73% and 84% respectively. Even if we Base CRL 143 143 142857 142857 reduce the validity period of the delta CRLs Downloads (and increasing the timeliness of the infor- [day-1] Delta CRL 1000 10000 1000000 10000000 mation at the same time) in the Big CA Downloads setup, the load on the network remains lower 4 [day-1] than with full CRLs. Only for the small CA, Bandwidth 0,58 3,1 310 000 640 000 the network load is higher than in the full [MB/day] CRL case, 3,1 MB per day compared to 2,1 Table 3: Expected Delta CRL Performance MB per day. Delta CRLs can reduce the bandwidth Small CA Big CA consumption significantly. Table 3 shows Signature Creations 10 003 10 003 014 that the CA can issue delta CRLs even more [day-1] frequently while the bandwidth consumption Request Size [Byte] 250 250 is still much lower than for full CRLs. To Response Size [Byte] 1 250 1 250 get comparable results, we included a delta Bandwidth [MB/day] 14,3 14 305 Table 4: Expected OCSP Performance CRLs case with the same timeliness con- straints, which we had for the full CRL case; Table 4 gives a performance estimation i.e. there is one column for the small CA and for an OCSP responder for our two CA con- for the big CA for which the delta CRL va- figurations. This table is simpler because lidity is 24 hours—the same value as the there is nothing such as a validity period. CRL validity in Table 2. To get an impres- Even if the OCSP responder gets its status sion how the results would change due to a information from CRLs, it makes no per- reduction of the delta CRL validity, we formance difference, which would reflect in added another column for each CA with the table. If the OCSP responder gets its smaller delta CRL validity—two hours in status information from CA database di- this case. In contrast to the full CRL case, rectly instead of from CRLs, the CA could with delta CRLs, the CA has to create a abandon CRLs completely. In addition, it similar number of signatures. Only a few would enable the OCSP responder to pro- vide real-time status information and posi- 4 Note that the number of delta CRL downloads per tive status responses (this requires a day will not be higher than the overall number of non-standard extension like the CertHash certificate validations per day, which is the product of certificate validations per day (per certificate) and the extension in [12]). In contrary to the CRL number of certificates. case, for OCSP the bandwidth consumption 55 4th Annual PKI R&D Workshop Pre-Proceedings increases linearly with the number of certifi- validations and the timeliness requirements cate validations. With CRLs, the client for revocation information. Up to now, time- downloads a CRL and does all revocation liness requirements seem to have a low pri- checking based on it until it expires. With ority for CAs because there are many CAs OCSP, the client has to get a separate OCSP which do not offer OCSP responders and response for each certificate validation. The those of which who implement their servers caching of responses gives no benefit unless to provide no more current revocation in- the client always validates the same certifi- formation than the latest CRL does. It is cates. unclear if there is not enough demand from the customers for up-to-date status informa- As we can see in the table, the bandwidth tion, or if the CAs are reluctant to implement consumption is quite affordable. While it is better OCSP servers. a little higher for the small CA, it is smaller by an order of magnitude for the big CA. Proposal for an on-line PKI For the small CA, the OCSP responder pro- Certification Authorities issue certifi- duces 14,3 MB traffic per day compared to cates. Users who receive such a certificate 2,1 MB with full CRLs and 0,58 MB and 3,1 need to find out, if the data in the certificate MB with delta CRLs. In large environments, is valid with respect to a certain time. For the difference is tremendous. Here, the digital signatures, this is the time of signa- OCSP responder causes about 14 GB net- ture creation. In case of encryption, it is usu- work traffic per day compared to 1900 GB ally the current time. The application per- with full CRLs and 310 GB and 640 GB forms revocation checking to find out if the with delta CRLs. In addition, an OCSP re- certificate is valid. Other steps are also re- sponder can give real-time status informa- quired, but applications can typically proc- tion—CRLs cannot. These 14 GB per day ess them with locally available data. Certifi- (0,17 MB per second) are an affordable cate chain building, for example, is often bandwidth, not only for a corporate network rather easy because most protocols like se- but also for Internet connections. cure email and SSL/TLS recommend send- These simple calculations already give a ing the complete certificate chain anyway. clear impression of the scalability of the Fortunately, most implementations stick to different revocation mechanisms used in this recommendation. practice. OCSP scales much better than Is revocation checking always required? CRLs. As well, OCSP can provide more If we assume that the start of the validity current revocation information than CRLs. period of a certificate corresponds to the For small CAs, CRLs may cause slightly time when the certificate has been issued, an less network traffic, but also provide less application would not need to check a cer- timely status information. OCSP can show tificate for revocation with respect to this its advantages in large environments, where time. In fact, a certificate does not say any- it can reduce the network traffic massively. thing about its validity. Even the validity However, all these calculations are valid period is only defined to specify the time only for two simple but reasonable setups. interval during which the issuing CA guar- The results can vary depending on various antees to provide status information. Cur- factors of the environment, including the rently, there are new standards for certificate number of issued certificates, the number of validation on the way. One of the most certificate users, the number of certificate prominent ones is the Simple Certificate 56 4th Annual PKI R&D Workshop Pre-Proceedings Validation Protocol, short SCVP. The PKIX each time instant at which the signer creates working group develops this standard. It a signature. An important difference is that should enable clients to off-load the com- the validity period of such certificates would plete task of certificate validation. The client always be in the past (with respect to the sends a request to the service for validation issuing time) or would at most extend to the of a certain certificate. As a result, it gets the current time. validation result. This approach has several advantages. Developers with no PKI knowledge may First, there is no need for additional revoca- ask, if we need certificates at all. This is a tion checking. The issued certificate would legitimate question. The client has to trust already transport all information to the re- the validation server anyway to provide cor- cipient—the signer was the legitimate owner rect results, and it does not do any process- of this key at the signing time. For encryp- ing of the certificate itself any longer despite tion, the time of interest is the current time, picking the public key and the identifier of and the sender would go for a certificate for the key owner. In many cases, it would be the intended recipient. sufficient to add the signer’s name and the signature verification key to a signature. The One apparent disadvantage is the required verifier could then ask the validation server on-line access for the client. Having a closer if this signer was the legitimate owner of the look, the requirements are the same as if the verification key at the time of signature crea- user would have to perform revocation tion. The validation server could still employ checking with up-to-date status information. certificates for its internal processing and This is also only possible with on-line ac- select the appropriate ones. However, if the cess. Users and applications can still use old CA runs the validation server, there seems to certificates if they do not have such high be no point in using certificates in the tradi- security demands. Here, the decision is up to tional way. Accessing databases seems to be the users if they accept out-dated informa- simpler and more efficient. The signer could tion about the binding between alleged key add a link to the certification authority to the owner and key or if they go for reliable and signature to support the client in selecting definitive information. the right one for validation. It may even make sense to have more than one authority An additional improvement is the re- at the same time. The recipient can pick a duced complexity. Only one format is re- trusted one or may validate with several or quired for certificates, no additional format all of them to increase the trust in the result. for CRLs or OCSP or any other validation It would also be possible that the signer al- service. The existing certificate format could ready gets a signed validation result from the even serve as the request format for this authority at the time of signature creation. on-line certification service. The request The validation result is actually nothing else would not need a signature though. The re- than a certificate. The recipient can still do sponse would be just a certificate. The valid- its own validation on demand. Thus, the ity period of this certificate would be just a same format can be used. All we need is an single time instant or maybe a period in the on-line service for certificate issuing from past. For the past, the certification authority the CA. The requirements for such a service would be able to provide definitive answers. would be pretty much the same as for an Thus, revocation may not be required at all, OCSP service. The CA would issue a new in the sense it is used today. certificate for each signature, or at least for 57 4th Annual PKI R&D Workshop Pre-Proceedings Business cases would also be simpler and voke. After revocation of the binding, the more flexible with this approach. A com- CA would simply no longer issue certifi- mercial CA would be able to charge on a cates via its on-line certification service for per-use basis, for example, per issued sign- this combination of key and user. There is ing certificate. Since the CA does not need no need to revoke any old certificates it is- to run an additional revocation checking sued before because the certificate state- service, the resource planning is also easier ments refer to a time in the past before the and more predictable. Just imagine that Mi- revocation took place. crosoft enables certificate revocation check- ing using CRLs per default in their Internet What is the performance of such a simpli- Explorer. Commercial CAs would face fied on-line certification PKI? The band- tough times providing their large CRLs for width consumption is actually the same as millions of clients in the world. for OCSP, assuming that the requests and responses are roughly of comparable size. The workflow for setting up a relation or This seems to be a reasonable assumption. contract between the user and the CA can remain the same. The CA can issue a first Small CA Big CA certificate during this initial phase. Even Signature 10 000 10 000 000 Creations though the client does not really need this [day-1] certificate, it may help ensuring compatibil- Request Size 500 500 ity with existing applications. The client [Byte] could even use just a self-signed certificate Response Size 1 000 1 000 instead because it also includes the required [Byte] public key and name. Moreover, a self- Bandwidth 14,3 14 305 [MB/day] signed certificate can serve as a proof of Table 5: Expected performance for on-line certi- possession during the registration. If the fication client registers its public key at several CAs, it would not need to have several certifi- Table 5 shows the expected performance cates. There is nothing wrong with the regis- values at the CA side. The number of re- tration of the same user-to-key binding at quired signature creations is even slightly several CAs. It would only cause different lower than for OCSP because for OCSP the CAs to vouch for the same statement. In CA has to issue certificates and OCSP re- fact, this is an increase of security because it sponses. Here, we only have one signature may be possible that a single CA makes mis- for each certificate, the total number of takes, but it is less likely that several inde- which is the same as for OCSP responses. In pendent CAs make the same mistake. practice, the situation may be even better because clients typically do not cache OCSP The client actually needs just its identifier responses. Thus, they get an OCSP response (something like the subject name) and its each time they validate a certificate, even if key-pair. For further communication with they validate the same certificate with re- the CA, it can use this signature key and the spect to the same time. In the case of on-line identifier to authenticate the requests to the certification, when the signer already at- CA. A request can be for lengthening the taches the certificate to the signature, the contract with the CA or for revocation of a verifier may not ever need to go for a new key-to-identifier binding. Note that there is certificate. no revocation of a single certificate any longer because there is no certificate to re- 58 4th Annual PKI R&D Workshop Pre-Proceedings For the big CA, the on-line certification They only need to handle the certificate service needs to perform 10 million signa- format, which can remain the same as al- ture creations per day, which are about 116 ready used in current systems. As a result, signature creations per second. This is an existing protocols like S/MIME [5] and amount, which modern server systems can SSL/TLS [4] can run without modification. easily process with pure software implemen- Some other protocols can even be simplified tations of cryptographic operations5. An because there is no need to support CRLs, on-line certification system would use se- OCSP and other revocation checking for- cure crypto hardware anyway for sheer secu- mats and protocols any longer. rity requirements. Modern hardware security modules (HSMs) are typically able to per- The service’s signature key is an attrac- form several hundred operations per second. tive target for attacks. This is a drawback, There are some HSMs available which can even though it is manageable with dedicated create several thousand signatures per sec- security devices. If an adversary can get the ond,6 and there are crypto processors which signature key of the service, it can issue cer- can perform several ten-thousands per sec- tificates at will. Current CAs often issue ond7. Thus, even for large CAs, an on-line certificates off-line and just issue revocation certification service seems to be feasible information on-line. Getting the signature with off-the-shelf hardware. key of the revocation service is not sufficient for issuing certificates, though the ability to Compared with CRLs and delta CRLs, issue wrong revocation information may on-line certification is a clear tradeoff be- allow attacks with similar severe effects. tween network bandwidth and processing power. On small-scale PKIs, on-line certifi- Conclusion and Further cation can require even more bandwidth than CRLs, but in large-scale PKIs, it per- Work forms equally well as OCSP. At the same During this work, we analyzed a few time, on-line certification can provide the typical PKI setups. Not surprisingly ([11]), it latest key status information, which an turned out that CRL-based revocation check- OCSP responder can also do, but CRLs and ing consumes a lot of bandwidth, especially delta CRLs cannot. for large CAs with many certificates and many users. For the proposed type of on-line On the client side, on-line certification certification, the requirements for the signa- can bring a significant reduction of com- ture creation performance are higher than for plexity because additional revocation check- CRLs, but they are at most as high as for an ing is no longer required. Moreover, clients OCSP responder. Unlike CRLs and certain need to handle less different data formats. OCSP responders, on-line certification pro- vides always the latest status information. This approach also reduces the complexity 5 For example, OpenSSL 0.9.7d compiled with as- of PKI systems because it eliminates the sembler optimizations on an AMD Opteron 146 with need for additional revocation checking, and 2 GHz performs about 900 signature creations per second using RSA 1024 bit keys (using CRT). in consequence, there is no need to support 6 The Sun Crypto Accelerator 4000 PCI Card can additional formats and protocols like CRLs create 4300 RSA signatures per second with 1024 bit and OCSP. In summary, the system re- keys using CRT. quirements regarding bandwidth and proc- 7 A NITROX Security Processor from Cavium Net- essing performance are comparable to works can perform up to 40 000 RSA signatures per second with 1024 bit keys using CRT. OCSP. Thus, existing hardware and software 59 4th Annual PKI R&D Workshop Pre-Proceedings components are sufficient to implement an While recent work often increases the on-line certification system. overall complexity of PKI systems and thus diminishes its attractiveness, on-line certifi- On-line certification has some neat prop- cation can offer a real reduction of complex- erties, which makes it appealing to certain ity while improving utility. business cases. A pay-per-use scheme seems to be easy to implement. Its behavior is also References better predictable than that of current sys- [1] Housley, R., Ford, W., Polk, W., Solo, tems, which include separate revocation D.: Internet X.509 Public Key Infra- checking. Overall, the introduction of an structure, Certificate and CRL Profile. on-line certification service is more of a The IETF, RFC 3280, April 2002, avail- technical nature than an organizational one. able online at Thus, the existing organizational environ- http://www.ietf.org/rfc/rfc3280.txt ment can often remain unchanged. Even [2] Myers, M., Ankney, R., Malpani, A., many parts of the technical equipment can Galperin, S., Adams, C.: X.509 Internet remain unaffected or may require only small Public Key Infrastructure, Online Cer- adaptations. On the client side, the reduction tificate Status Protocol – OCSP. The in complexity is even more evident. This can IETF, RFC 2560, June 1999, available online at make PKI attractive even for such environ- http://www.ietf.org/rfc/rfc2560.txt ments where current PKI systems would [3] Adams, Carlisle, Lloyd, Steve, “Under- entail an unacceptable increase of complex- standing the Public-Key Infrastructure”, ity. New Riders Publishing, ISBN: 157870166X The next step towards an on-line certifi- [4] Dierks, T., Allen, C.: The TLS Protocol, cation service would be the more detailed Version 1.0. The IETF, RFC 2246, Janu- specification of a protocol. Such a service ary 1999, available online at would have to be as simple as possible. A http://www.ietf.org/rfc/rfc2246.txt prototype implementation as a proof-of- [5] Ramsdell, B. (Editor): S/MIME Version concept would also help to get a clearer im- 3 Message Specification. The IETF, pression of the advantages and disadvan- RFC 2633, June 1999, available online tages of this approach. It would also allow at http://www.ietf.org/rfc/rfc2633.txt benchmarking in different environments and [6] Doyle, P., Hanna, S.: Analysis of June use-cases. Measured values from real im- 2003 Survey on Obstacles to PKI De- plementations are more convincing than ployment and Usage. The OASIS Public theoretical calculations. Key Infrastructure (PKI) Technical Committee (TC), Version 1.0, 8 August Two important issues have not been con- 2003, available online at sidered yet. The first is the setup of trusted http://www.oasis- root keys. Even though, the same techniques open.org/committees/pki/pkiobstaclesju as for the setup of trusted root certificates ne2003surveyreport.pdf are applicable, simpler and more elegant [7] Myers, M.: Revocation: Options and mechanisms are desirable. The second is the Challenges. Financial Cryptography process of revocation itself, i.e. the actions 1998, Springer-Verlag Berlin Heidel- berg 1998, LNCS 1465, pp. 165-171. the key owner can take to notify the CA [8] Cooper, D.: A Model of Certificate Re- about revocation. Current systems solve this vocation. Proceedings of the Fifteenth issue unsatisfactorily. Annual Computer Security Applications 60 4th Annual PKI R&D Workshop Pre-Proceedings Conference (ACSAC), pages 256-264, December 1999. [9] Rivest, R.: Can We Eliminate Certificate Revocation Lists? Financial Cryp- tography 1998, Springer-Verlag Berlin Heidelberg 1998, LNCS 1465, pp. 178- 183. [10] Fox, B., LaMacchia, B.: Online Certifi- cate Status Checking in Financial Trans- actions: The Case for Re-issuance. Fi- nancial Cryptography 1999, Springer- Verlag Berlin Heidelberg 1999, LNCS 1648, pp. 104-117. [11] Berkovits, S., Chokhani, S., Furlong, J., Geiter, J., Guild, J.: Public Key Infra- structure Study, Final Report. Produced by the MITRE Corporation for NIST, McLean, Virginia, April 1994. [12] Common ISIS-MTT Specifications for Interoperable PKI Applications from T7 & TeleTrusT. Version 1.1, 16 March 2004, available online at http://www.isis-mtt.org [13] Kohnfelder, L.: Towards a Practical Public-Key Cryptosystem. Bachelor Thesis, MIT, May 1978. [14] Ellison, C.: Naming and Certificates. Proceedings of the tenth conference on Computers, freedom and privacy, pp. 213-217. Toronto, Ontario, Canada, April 2000. 61 4th Annual PKI R&D Workshop Pre-Proceedings Delegation Issuing Service for X.509 D.W.Chadwick, University of Kent, Canterbury, CT2 7NZ, England by its superior AA, and may delegate these Abstract further to subordinates (AAs or end entities). This paper describes the concept of a A subordinate who is not allowed to delegation issuing service (DIS), which is a delegate further is termed an end entity. In service that issues X.509 attribute the normal situation all privilege holders certificates on behalf of an attribute (AAs and end entities) are allowed to assert authority (typically a manager). The paper the privileges that are delegated to them. defines the X.509 certificate extensions that are being proposed for the 2005 edition of However, in some situations a privilege X.509 in order to implement the DIS holder may be allowed to delegate the held concept, as well as the additional steps that a privileges to a subordinate, but may not be relying party will need to undertake when allowed to assert the privileges itself. An validating certificates issued in this way. example might be an airline manager who The paper also presents our initial assigns privileges to pilots to fly particular experiences of designing a DIS to add to the aircraft, but is not allowed to fly the aircraft PERMIS authorization infrastructure. The himself, or a hospital manager who assigns paper concludes by reviewing some of the privileges to doctors on duty but is not previous standards work in delegation of allowed to assert these privileges himself. authority and anticipating some of the Whilst the X.509 standard recognizes this further standardization work that is still scenario, it offers no support for this in the required in the field of privilege ACs that can be issued to these AAs i.e. management. there is no way of signaling to a relying party (RP) that an AC holder may not assert 1. Introduction the privileges contained in the AC that it The 2000 edition of X.509 [1] defines a holds. This deficiency needs rectifying. Privilege Management Infrastructure (PMI) based on attribute certificates (ACs). Work is now progressing towards issuing Attribute certificates are very similar to the 2005 edition of X.509, and another public key certificates (PKCs) but hold delegation scenario has been identified in privileges (as attributes) instead of public the draft amendment [2] to X.509(2000). keys. In the X.509 PMI model, the root of This concerns the use of a delegation service the PMI is termed the Source of Authority to issue ACs on behalf of other AAs. The (SoA), and subordinates are termed delegation issuing service (DIS) concept Attribute Authorities (AAs). Delegation of recognizes that in some organizational Authority passes down the chain from SoA contexts, it might be preferable for a to AA to subordinate AAs in much the same manager (an AA) who wishes to delegate way as the authority to issue public key authority to a subordinate, be not certificates passes down a PKI certification empowered to issue the X.509 AC herself, authority hierarchy from the root CA to but rather should request a DIS to issue the subordinate CAs (see Figure 1A). A AC on her behalf. subordinate AA is given a set of privileges 62 4th Annual PKI R&D Workshop Pre-Proceedings Points to AC holder Points to issuer SOA Bill SOA Bill Points to Issued On Issues Behalf Of AC to Issues AC to Issues AC to AA Alice AA Alice Delegation Issues AC to Issues Issuing AC to Service Bob End End Bob Entity Entity Figure 1A. Normal Figure 1B. Delegation of Authority using a Delegation of Authority Delegation Issuing Service Thirdly, the manager does not need to hold 1.1 Advantages of a DIS and maintain her own private signing key, The benefits of using a delegation issuing which would be needed if the manager were service instead of AAs issuing X.509 ACs to issue and sign her own ACs. Only the DIS themselves are several. Firstly, the DIS can needs to have an AC signing key. This could support a fully secure audit trail and be a very important feature in organizations database, so that there is an easily accessible that use mechanisms other than PKIs for record of every AC that has been issued and authentication such as biometrics, user revoked throughout the organization. If each names and passwords, or Kerberos etc. manager were allowed to independently Finally, if the DIS is given its own AC by issue their own ACs, then this information the SOA, it can replace the (set of) would be distributed throughout the manager’s AC(s) in the AC validation chain organization, making it difficult or and therefore decrease the complexity of AC impossible to collect, being possibly badly chain validation. The AC chain length or never recorded or even lost. Secondly, the would always be two when the DIS issues DIS can be provided with the organization’s the ACs to end entities, whereas it would be delegation policy, and apply control of arbitrary length when the managers issue procedures to ensure that a manager does the ACs themselves. Also less CRLs will not overstep her authority by issuing greater need to be issued – only the DIS will need to privileges to subordinates, or even to herself, issue a CRL rather than each manager. This than the organization’s policy allows. will further simplify AC chain validation. 63 4th Annual PKI R&D Workshop Pre-Proceedings 1.2 DIS Deployment Models 1.3 Disadvantages of a DIS Two deployment models for the DIS are As mentioned above, in PKI (and AC PKI) envisaged in the 2005 draft amendment [2]. modes, AC chain validation is more In both models the DIS is empowered to complex when a DIS issues the ACs. issue ACs on behalf of other AAs, by being Another potential disadvantage of a DIS is issued with its own AC by the SoA. This AC that the single CRL issued by the DIS could confers on the DIS the authority to issue get very large, unless distribution points are ACs on behalf of other AAs. This used. A large CRL can adversely affect the empowerment model is similar to the PKI performance of AC chain validation. concept of an indirect CRL issuer, whereby Further, when cross certification between an entity is given the authority to issue PMIs takes place, in PMI mode there is a CRLs on behalf of a CA. In the first DIS loss of granularity since it has to be the DIS deployment model (which we have called that is cross certified rather than any of the the AC PKI mode), a privilege holder AAs that are trusted. But perhaps the biggest requests the DIS to issue privileges on its disadvantage of using a DIS for some behalf, but the DIS does not actually hold applications is that the AC signing key the privileges itself. The AA tells the DIS should be online and ready to be used to which privileges to delegate. In the second sign ACs when requested. In some highly deployment model, the DIS is actually given secure systems this would be unacceptable. the privileges to be delegated by the SoA (we have called this the PMI mode). 1.4 Paper Contents However, the 2005 draft amendment had no This paper describes proposed extensions to mechanisms for implementing either of the 2000 edition of X.509 that can be used to these deployment models. implement the DIS model for delegation of authority, as well as rectify the 2000 In our research and design of a DIS service deficiency that there is no way to signal that for PERMIS [5], we have also identified a an AA holds a privilege for delegation but is third deployment model in which the DIS is not allowed to assert the privilege. These not given an AC, but has its own PKI key extensions have recently been included as pair for signing the ACs its issues, with part of the revised draft amendment to empowerment flagged in the public key X.509(2000). certificate (we call this the PKI mode). The DIS now only needs to authenticate the AAs The rest of this paper is structured as and issue ACs on their behalf, without follows. Section 2 describes the X.509 validating the contents of the ACs. extension that can be used to signal that a Furthermore, the users do not need to have privilege holder is not allowed to assert the their own PKI key pairs. This simplifies the privileges that it holds. This corrects the design and deployment of the DIS service, deficiency in the 2000 edition of X.509. but the downside is that it complicates the Section 3 describes the X.509 extensions process of AC chain validation by the that can be used to implement the DIS relying parties due to the delegation model. Section 4 describes how relying indirection introduced by the DIS, as parties will need to use these new extensions described later. in order to validate ACs issued by a DIS. Section 5 describes how we are implementing the DIS in PERMIS. Section 6 describes related standards work and 64 4th Annual PKI R&D Workshop Pre-Proceedings research in this area, whilst Section 7 noAssertion EXTENSION ::= { describes further standardization work that SYNTAX NULL is still needed to be done in the X.509 PMI IDENTIFIED BY { id-ce- framework. noAssertion } } 2. No Assertion of Privileges where id-ce-noAssertion is an object There are two scenarios where privilege identifier (OID) assigned in X.509. holders may be given privileges in an AC1, in order to delegate them to other entities, If present, this extension indicates that the but where they are not allowed to assert the AC holder cannot assert the privileges privileges themselves. The first is where a indicated in the attributes of the AC. This manager is tasked with allocating roles or field can only be inserted into AA ACs, and duties to subordinates, but is not allowed to not into end entity ACs. If present, this assert the roles or duties himself. The extension shall always be marked critical. previous section gave a couple of examples of this scenario, in the shape of an airline 3. X.509 Extensions to Support manager and a hospital manager. This the Delegation Issuing Service scenario is represented by Alice in Figure As described in the Introduction, three 1A. The second scenario is where a deployment models have been identified for delegation issuing service (DIS) is given a the DIS, two in [2], in which the DIS is set of privileges to delegate, as directed by issued with its own AC and we have termed the SoA. This is represented by the the AC PKI and PMI modes, and one from Delegation Issuing Service in Figure 1B. our own research, termed the PKI mode, in which the DIS does not have its own AC. We can prevent the holder of these privileges (Alice in Figure 1A and the DIS 3.1 DIS Empowerment in Figure 1B) from asserting them by The Delegation Issuing Service (DIS) needs placing a “no assertion” extension into the to be empowered by the SoA to issue ACs AC issued to it. This extension will inform on behalf of other AAs. This is done by all relying parties that understand the including an “indirect issuer” extension in extension that the AC holder is not allowed either the PKC or the AC issued to the DIS to assert the privileges contained within the by the CA or SoA respectively. The indirect AC. This extension obviously needs to be a issuer extension serves a similar purpose as critical extension, since any relying party the indirect CRL boolean of the issuing that does not understand it, must refuse to distribution point extension in PKI CRLs i.e. accept the AC, rather than simply ignore the it gives authority to the DIS. The indirect extension and allow the privileges to be issuer extension is formally defined in asserted. ASN.1 as: The “no assertion” extension is formally indirectIssuer EXTENSION ::= { defined in ASN.1 [6] as: SYNTAX NULL IDENTIFIED BY id-ce- 1 We do not consider it sensible to issue privileges to indirectIssuer } AAs via the subjectDirectoryAttributes extension of public key certificates, since the AAs would not be where id-ce-indirectIssuer is an OID allowed to delegate these privileges further by issuing assigned in X.509. additional PKCs, since they are not a CA. 65 4th Annual PKI R&D Workshop Pre-Proceedings The indirect issuer extension may be used policy to request the AC to be issued, the by the relying party when validating an AC DIS will issue an AC on behalf of the chain to check that the AC issuer was requesting AA. Thus we need an extension empowered to issue ACs on behalf of other to be inserted into the AC, informing all AAs (otherwise anyone with a signing key relying parties that this certificate was issued could issue an AC and say it was authorized on behalf of a particular AA. This leads to by an AA). Alternatively, it may be used by the requirement for the “issued on behalf of” the DIS software at initialization time to extension, which is formally defined in check that it is empowered to act as a DIS. ASN.1 below. The draft extension to X.509 states that the issuedOnBehalfOf EXTENSION ::= { indirect issuer extension may be placed in SYNTAX GeneralName either an AC or PKC containing the IDENTIFIED BY id-ce- subjectDirectoryAttributes extension issued issuedOnBehalfOf } to a DIS by an SoA. In our research we have identified that this extension may also be where id-ce-issuedOnBehalfOf is an OID placed in a PKC that does not contain the assigned in X.509. subjectDirectoryAttributes extension. This extension is inserted into an AC by an The presence of this extension means that indirect issuer. It indicates the AA that has the subject AA (the DIS) is authorized by requested the indirect issuer to issue the AC, the SoA to act as a proxy and issue ACs that and allows the delegation of authority chain delegate privileges, on behalf of other to be constructed and validated by the delegators. This extension is always non- relying party if necessary (see section 4). critical, since it does not matter to a relying party if it understands this extension or not The GeneralName is the name of the AA when the DIS is acting as a privilege asserter who has asked the issuer to issue this AC by presenting this to the RP to assert the privileges contained within this certificate. The issuer of this AC must have been This extension can be used by a RP when granted the privilege to issue ACs on behalf validating an AC chain which has the DIS of other AAs by an SOA, through the acting on behalf of another AA somewhere indirectIssuer extension in its AC or PKC. in the AC chain (see section 4). This extension may be critical or non-critical 3.2 Requesting an AC as necessary to ensure delegation path When an AA wishes to delegate some of its validation (see next section). privileges to a subordinate, and wishes to use the services of a DIS to issue the AC on 4. Validating Indirect AC chains its behalf, it needs to contact the DIS to The X.509 standard already provides a request the certificate to be issued. How this procedure for validating privilege paths and communication is achieved is outside the delegation chains in the standard delegation scope of X.509. Some discussion of this is of authority scenario. This chain is provided later. Assuming this represented by the curved arrows that point communication is successful, i.e. that the to issuers in Figure 1A. This procedure AA is authenticated to the DIS, and is needs to be enhanced when indirectly issued allowed by the DIS’s attribute allocation ACs are encountered in the delegation chain, 66 4th Annual PKI R&D Workshop Pre-Proceedings such as those in Figure 1B. As can be seen In PKI mode, the DIS does not have an AC, from the addition of the issuedOnBehalfOf but only has a PKC containing the arrows in Figure 1B, the procedure is more indirectIssuer extension. In this case the complex and more delegation links need to ACs issued by the DIS have to have the be validated when this extension is marked issuedOnBehalfOf extension set to critical, critical. since the DIS is incapable of performing any validation of the requesting AA other than Three deployment models have been authenticating that it is who it says it is. All identified, which we have termed the AC PMI validation has to be done by the RP. PKI, PMI and PKI modes. In PMI mode, the But this is in fact little different to the DIS has been issued with an AC by the validation performed in the AC PKI mode, SOA, which contains a superset of the and is if anything slightly simpler since the attributes that it will issue on behalf of other DIS only has a PKC to be validated and not AAs. This model presents the simplest path a PKC and an AC. validation processing, since the AC chains will always comprise of just two ACs: the In addition to the standard procedural tasks end entity’s AC signed by the DIS, and the of validating signatures and revocation lists, DIS’s AC signed by the SOA. The existing the relying party will also have to perform standard path validation procedure will work the following additional steps. for this AC chain. The RP may safely ignore the issuedOnBehalfOf and indirectIssuer i) Starting with the end entity’s AC, the extensions which will be marked as non- RP will need to extract the issuer critical, since the DIS had full authority to name and look at the critical flag of issue the ACs to the end entities even though the issuedOnBehalfOf name. in reality it was a peer AA that asked for the ii) If the issuedOnBehalfOf extension is delegation to be performed. Note that the marked critical, the RP retrieves the DIS might not have permission to assert ACs of the issuedOnBehalfOf AA these privileges itself, but that will be and validates that the AA has a signaled separately by the noAssertion superset of the privilege attributes extension. issued to the end entity and that the ACs have not been revoked. If it In AC PKI mode, the DIS has an AC does not have sufficient privileges, containing the indirectIssuer extension, but or they have been revoked, the end does not have any of the attributes that it entity’s AC is rejected. The RP will issue to others. These are held by the retrieves the certificates (ACs and AAs that request the DIS to issue the ACs. PKCs) of the issuer and validates In this case the issuedOnBehalfOf extension that the issuer is an indirect issuer of must be set to critical, since the RP will need the SoA (i.e. has the indirectIssuer to validate that the requesting AA had extension in one of its certificates). If sufficient privileges to delegate to the end not the end entity’s AC is rejected. entity. If the extension was not set to critical, iii) If the issuedOnBehalfOf extension is the RP is likely to compute that the AC missing or non-critical, the RP chain is invalid since the DIS issuer did not retrieves the ACs of the AA (the have a superset of the privileges that were DIS) and validates that the AA has a allocated to the end entity. superset of the privileges issued to the end entity. If not, the end entity’s 67 4th Annual PKI R&D Workshop Pre-Proceedings AC is rejected. nothing to stop this from happening. For this iv) For each AC of the issuer that reason, SPKI decided (in section 4.2 of [11]) contains one or more of the that they were powerless to stop this in their delegated privileges, the RP recurses simple certificates that tied authorizations to to step i) for each AC, thereby public keys. However, X.509 has the moving up the delegation chain. This advantage that AAs are given globally recursion continues until the RP unique names by CAs. Providing an AA is arrives at the AC of an AA that is not able to obtain an alias name for itself issued by the trusted SoA(s) who from the same or another trusted CA then is(are) the root(s) of the PMI. This the relying party can check if any AA’s AC validates that the privileges were in a certificate path has the noAssertion properly delegated. extension set, and if it does, apply it also to any subordinate ACs that contain the same 4.1 Validating the noAssertion holder name. Clearly if an AA is able to extension obtain totally unrelated aliases from one or If an AA’s certificate has the noAssertion more trusted CAs, then the RP is unlikely to extension in it, what is to stop the AA know that the AA is asserting privileges that issuing another AC to itself and omitting the it was not intended to, by using an alias noAssertion extension? Clearly there is name. 1 ACM ACM DIS Single Java program 2 Web Service Interface Web DIS Web Service browser SSL or 4 Shibboleth DIS SSL or Web Service 3 Shibboleth Interface Apache DIS Apache Figure 2. DIS Communications implementing dynamic delegation of 5. Implementing the DIS authority. However, a number of issues We decided to implement the DIS as part of needed to be resolved that are not addressed the PERMIS X.509 PMI, as an aid to in the proposed extensions to X.509. 68 4th Annual PKI R&D Workshop Pre-Proceedings Firstly there is no mention of how the limit AC path lengths to two, and if the communication between the DIS and the AA target policy is willing to trust the DIS as a should be achieved. Clearly the use of a root (as well as the SoA) then path standardized protocol is preferable to a validation lengths are reduced to just one proprietary one. One can envisage that an AC, that of the end user. IETF working group such as PKIX might define a protocol similar to CMP [3], using a In our implementation, the DIS is given an request similar to a PKCS#10 message [4]. AC containing a full set of privileges, and is In the absence of such a standard, in our configured with its own PERMIS PDP. The own research we are proposing to use a Web PDP is configured with an attribute (or role) Services protocol (see d in Figure 2), and assignment policy (RAP) [7], so that it can the Java GSSAPI [19] for authenticating the validate the AA requests. At initialization user. The GSS tokens will then be base64 time the DIS will check that its AC has the encoded and inserted into SOAP messages. indirectIssuer extension in it, otherwise it We are also defining a Java API for the DIS will fail to start. When an AA asks for an (see c in Figure 2), so that the DIS can be AC to be issued, the DIS will check that the built into other Java programs such as the AA is allowed to do this under the RAP PERMIS Attribute Certificate Manager policy, and also that the set of attributes (ACM) and called directly by it. In this case requested are a subset of those held by the user authentication is not necessary. We are DIS. Validation against the RAP is done by also proposing to adopt a 3 tiered model the existing PERMIS PDP code. It is passed where an Apache server acts as the DIS the (unsigned) AC requested by the AA, and client, authenticates the AAs via either it validates the credentials in the AC against Apache authentication (e.g. SSL) or the RAP. The only modification needed to Shibboleth (see f in Figure 2), and then PERMIS is to provide it with a null acts as a proxy for them to the DIS. It would signature validation object that will return also be possible for Apache to directly call signature valid to every request to validate the DIS via our Java API (see e in Figure the unsigned ACs. If the AC passes the 2). policy, the DIS will check that the requested attributes are a subset of those it holds in its Secondly there are a number of issues own AC. The task of the RP is now made concerned with AC path validation. As much simpler, since it only needs to validate pointed out by Knight and Grandy in [18] 1 or 2 ACs, that of the user issued by the this can be extremely complex when DIS, and optionally that of the DIS issued dynamic delegation of authority is by the SOA. implemented. We want to simplify this process as much as possible. We have Finally we wanted to simplify the use of already taken the step of not issuing role PMIs in organizations that do not have fully specification ACs, and instead we store their functional PKIs implemented. These contents in each target’s PERMIS policy organizations, which are in the majority, read in by its PDP at initialization time. We already have a fully functional user thus only issue role allocation ACs. Our authentication mechanism, and only have a preferred DIS deployment model is the PMI handful of PKCs, e.g. web server mode, since the DIS is issued with a role certificates. It is for this reason that we have allocation AC containing a superset of the chosen to implement communications attributes that it can delegate. In this way we between the user and DIS as a three tiered 69 4th Annual PKI R&D Workshop Pre-Proceedings model via an Apache web server as in path is provided with the PAC and the f in Figure 2. This will allow organizations appropriate CV (sent confidentially, of to use their existing authentication method. course). The delegate then presents the PAC One problem that has to be solved is that of to the target along with the CV. The target proxying, since the DIS will authenticate validates that the hash of the CV Apache, Apache will authenticate the user corresponds to a PV in the PAC, and if so and Apache will then ask for an AC to be allows the delegate to have the appropriate issued on behalf of the user. The DIS has to delegated access on behalf of the user. know if Apache is authorized to proxy in Different delegates can be given different this way. We could solve this in a couple of CVs which authorize different subsets of the ways. We could configure the details (name privileges contained in the PAC to different address of Apache) into the DIS. Or we sets of target resources. The EC SESAME could issue Apache with its own AC project [8] implemented a subset of ECMA containing a proxy privilege. When Apache Standard 219 and this was eventually rolled authenticates to the DIS, the DIS will call out into several commercial products from the PERMIS PDP to validate Apache’s AC, the project’s partners. The disadvantage of and if it has the proxy credential the DIS the ECMA scheme is that the user has to will allow it to request ACs be issued on know in advance of requesting the PAC behalf of other AAs. what delegation is required, since this is built into the PAC at the time of its issuance. 6. Related Research Some of the earliest standardization work ECMA Standard 219 supports both for attribute certificates and attribute symmetric and asymmetric encryption for certificate issuing servers was undertaken by protection of the PACs, since it supports ECMA in the late 80’s and early 90’s. This both Kerberos V5 [10] and digital signatures lead to the publication of ECMA Standard for user authentication to the authentication 219 [9] which specifies a model for server prior to contacting the PA-Server. distributed authentication and access Interestingly, X.509 decided to standardize control. The Privilege Attribute Certificates on only asymmetric encryption for its (PACs) described therein are a forerunner of certificates, whereas Microsoft Windows the attribute certificates later standardized in decided to adopt Kerberos and symmetric X.509. A Privilege Attribute Server (PA- encryption for its tokens when allowing Server) is responsible for issuing PACs to users to gain access to multiple Windows users, and is similar in concept to the DIS services. described in this paper. However, to support delegation of authority between principals, The Simple Public Key Infrastructure new PACs are not issued to the delegatees (SPKI) [11] IETF working group, whose (as in this paper) but rather the PA-Server work eventually merged with the Simple provides the initial user with a PAC that Distributed Security Infrastructure (SDSI) contains one of more embedded Protection [12] of Ron Rivest, defined three types of Values (PVs) that can be used for certificate which mapped names, subsequent delegation. A PV is a hash of a authorizations and group names respectively secret Control Value (CV). The user is to public keys. Authorization certificates can separately issued with the corresponding be further delegated, and this is indicated by CVs. When a user wishes to delegate a Boolean flag set by the issuing delegator. authority to another user or server, the latter The delegator can set the Boolean as 70 4th Annual PKI R&D Workshop Pre-Proceedings desired, except that if the Boolean is already can also carry information about which false in the authorization certificate privileges are being delegated, i.e. none, all delegated to him/her then it cannot be or a subset, the latter being defined in an switched back to true and be trusted. It application specific way. Grid applications therefore would be easy to apply the DIS and users could use the DIS framework concept and service to SPKI using the PMI described here as an alternative to the latter, mode deployment model, i.e. where the DIS and ask the DIS to issue ACs to their grid is delegated an authorization certificate with jobs that contain a subset of the privileges the Boolean set to true. However it would contained in the user’s AC. We plan to break the theory of SPKI to implement demonstrate this feature in due course, since either of the two PKI mode deployment PERMIS is already integrated with Globus models since these require the toolkit [14]. issuedOnBehalfOf extension to be present in the delegatee’s certificate, and this would More recently the work on Shibboleth [15] mean that the certificates are no longer has implemented a limited mechanism for simple according to SPKI’s definition. delegation of authority. In this case a target site delegates to the user’s home site the task One feature included in SPKI that is not of authenticating and assigning attributes to formally in the X.509 standard, is a rights the user. The user’s privileges are returned language for expressing authorization to the target site in the form of a SAML policies. Consequently PERMIS defined its Attribute Statement [16] signed by the home own policy language, written in XML [7]. site. In research described in another paper SPKI uses S-expressions. X.509 has left it to at this conference [17], we have extended other standards, e.g. the ISO Rights the Shibboleth delegation model by Expression Language [20] to specify the integrating it with PERMIS and X.509 ACs. policies. This means that the policy rules by The DIS will then be able to be used by which a DIS operates are not specified in home sites to delegate privileges even X.509. further. Proxy certificates, defined initially by the 7. Further Work Globus grid software developers, and later As indicated above, a protocol for published as an IETF proposed standard interactions between an AA and a DIS will [13], use a different model for delegation of need to be standardized so that requests to authority. In this model a user, who is the issue ACs can be made in a standard subject of a public key certificate (and manner. This request-response protocol may defined as an end entity by the X.509 be similar to the PKIX CMP protocol, but it standard), issues his own PKC (called a need not be, since proof of possession of the proxy certificate) to the public key of his private key is not essential (indeed one of grid job which has previously generated its the motivations for having a DIS is that the own key pair. Validating the proxy users may not have their own key pairs). In certificate of course breaks the standard many scenarios AAs may not be PKI users, X.509 certificate path validation rules, since but rather may use Kerberos, biometrics or an end entity is not allowed to act as a CA. symmetric tokens for authentication. In this To rectify this, a critical extension case the AAs are computationally unable to (proxyCertInfo) is added to the proxy issue X.509 ACs so will need to use the certificate to indicate the fact. The extension services of a DIS to issue the ACs on their 71 4th Annual PKI R&D Workshop Pre-Proceedings behalf. But they will be unable to sign those and made some constructive comments that requests to the DIS. In this case a web helped to improve it. services interface like the one we propose to use may be more appropriate, with the AA References using a web browser to interact with the DIS [1] ISO 9594-8/ITU-T Rec. X.509 (2000) via a web server, and perhaps authenticating The Directory: Public-key and attribute with a username and password over an SSL certificate frameworks link. Whatever protocol is standardized, it [2] ISO SC 6 N12596 “Proposed Draft will need to be flexible enough to cater for Amendment on Enhancements to Public- the different environments in which it may Key and Attribute Certificates”, Geneva be used. output, March 2004 [3] C. Adams, S. Farrell. “Internet X.509 Practical experience of working with X.509 Public Key Infrastructure Certificate PMIs is only just beginning. Most Management Protocols”. RFC 2510, March organizations who are experimenting with 1999 PMIs use them internally initially. They [4] Kaliski, B., "PKCS #10: Certificate define their own privilege attributes and Request Syntax, Version 1.5." RFC 2314, therefore the relying parties and SoAs have March 1998. a common understanding of both the [5] D.W.Chadwick, A. Otenko, E.Ball. semantics and syntax of these privilege “Role-based access control with X.509 attributes. However, as organizations move attribute certificates”, IEEE Internet towards role based or attribute based access Computing, March-April 2003, pp. 62-69. controls, and federations between [6] ITU-T Recommendation X.680 (1997) | organizations, including the formation of ISO/IEC 8824-1:1998, Information virtual organizations, they will find that the Technology - Abstract Syntax Notation One attributes and roles they have defined are (ASN.1): Specification of Basic Notation different from those in use by their [7] D.W.Chadwick, A. Otenko. “RBAC federation partners. When this starts to Policies in XML for X.509 Based Privilege occur, organizations will not want to re- Management” in Security in the Information issue ACs to users from the federated Society: Visions and Perspectives: IFIP organizations, but rather will wish to TC11 17th Int. Conf. On Information understand and use the ACs that have Security (SEC2002), May 7-9, 2002, Cairo, already been issued. This will require cross Egypt. Ed. by M. A. Ghonaimy, M. T. El- certification between PMIs, the mapping of Hadidi, H.K.Aslan, Kluwer Academic role allocation policies between Publishers, pp 39-53. organizations and constraints on what [8] T.Parker, D.Pinkas. “Sesame V4 foreign users may asserts in home domains. Overview”, Issue 1, Dec 1995. Available It is anticipated that this work will form the from bulk of the standardization activity for the https://www.cosic.esat.kuleuven.ac.be/sesa sixth edition of X.509. me/html/sesame_documents.html [9] Standard ECMA-219 "Authentication Acknowledgements and Privilege Attribute Security Application The authors would like to thank the UK with Related Key Distribution Functions" JISC for funding this work under the Parts 1, 2 and 3, December 1994. DyVOSE project, and the NIST PC [10] J. Kohl, C. Neuman. “The Kerberos members who robustly reviewed this paper Network Authentication Service (V5).” RFC 72 4th Annual PKI R&D Workshop Pre-Proceedings 1510, Sept 1993. (MPEG 21) — Part 5: Rights Expression [11] C. Ellison, B. Frantz, B. Lampson, R. Language [REL]”. 2004 Rivest, B. Thomas, T. Ylonen. “SPKI Certificate Theory”. RFC 2693, Sept 1999. [12] Ron Rivest and Butler Lampson, "SDSI - A Simple Distributed Security Infrastructure [SDSI]", See . [13] S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. “Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile”. RFC3820, June 2004. [14] David W Chadwick, Sassa Otenko, Von Welch. “Using SAML to link the GLOBUS toolkit to the PERMIS authorisation infrastructure”. Proceedings of Eighth Annual IFIP TC-6 TC-11 Conference on Communications and Multimedia Security, Windermere, UK, 15-18 September 2004 [15] Scot Cantor. “Shibboleth Architecture, Protocols and Profiles, Working Draft 02, 22 September 2004, see http://shibboleth.internet2.edu/ [16] OASIS. “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) v1.1”. 2 September 2003. See http://www.oasis- open.org/committees/security/ [17] David Chadwick, Sassa Otenko, Wensheng Xu. “Adding Distributed Trust Management to Shibboleth” presented at NIST 4th Annual PKI Workshop, Gaithersberg, USA, April 19-21 2005 [18] Knight, S., Grandy, C. “Scalability Issues in PMI Delegation”. Pre-Proceedings of the First Annual PKI Workshop, Gaithersburg, USA, April 2002, pp67-77 [19] Charlie Lai, Seema Malkani. “Implementing Security using JAAS and Java GSS API” Presentation from 2003 Sun JavaOne conference. See http://java.sun.com/security/javaone/2003/2 236-JAASJGSS.pdf [20] ISO/IEC 21000-5:2004, “Information technology — Multimedia framework 73 4th Annual PKI R&D Workshop Pre-Proceedings Meeting the Challenges of Canada’s Secure Delivery of E-Government Services Mike Just Danielle Rosmarin Public Works and Government Services Canada {mike.just, danielle.rosmarin}@pwgsc.gc.ca Abstract including interjurisdictional considerations, We describe a number of technical, legal, business registration, citizen enrolment, and policy and business issues related to the evidentiary support for electronic data. In development and deployment of Canada’s effect, we argue that tackling these issues is PKI-based solution for authenticating critical in order for Canada’s PKI-based individuals and businesses. We argue that secure e-government service delivery to be tackling these issues is critical in order for truly transformative. Even though other Canada’s PKI-based solution to truly jurisdictions’ legislative and policy transform Canada’s e-government services frameworks may differ from Canada’s, the delivery, and we offer insights into options spirit will likely be similar so that other that could resolve outstanding and jurisdictions and solution builders should remaining issues with this solution. gain some valuable information from our experience. 1 Introduction Beginning in 1999, the Canadian 2 Background Government initiated the Government On- Before we discuss the current issues related Line (GOL) project, which included the to secure service delivery, we review the development of an online presence for legislative and policy regime within Canada, approximately 130 of the most frequently and the technical solution supporting a used government services. The project also secure e-government service delivery, the included the provision of authentication Secure Channel (SC) infrastructure. services as part of the “Secure Channel” infrastructure, using public key credentials, 2.1 Legislative and Policy giving departmental programs the means for Instruments properly identifying and controlling access Politically, Canada is a federation in which to individuals’ personal information. Since the federal government is composed of the initial goals for the GOL project have approximately 130 departments and been accomplished, it is time to look to the agencies. There are 10 provinces and 3 future as more services move online, and territories, each with their own departments more complicated transactions are and agencies. Numerous legislative and supported. policy instruments govern their behaviour. In the federal government, each department While technology issues and decisions were mandate is captured in legislation. We will paramount in the early years for GOL, many briefly describe the legislation and policy of today’s issues reflect legal, policy and instruments that are most relevant to this business concerns. The technology solutions paper. are typically available or at least achievable; what remains is the deployment so as to best Public Works and Government Services meet these other concerns. In this paper, we Canada (PWGSC) delivers the SC identify several current issues related to the infrastructure supporting the secure delivery secure delivery of services to Canadians, of services, and is governed by the 74 4th Annual PKI R&D Workshop Pre-Proceedings Department of Public Works and enterprise communication environment for Government Services Act [DPW86]. This the federal government, the SC’s act stipulates that PWGSC is a common authentication services support the service agency for the Government of identification of citizens and businesses Canada (GoC), providing the GoC’s (hereafter referred to generically as departments, boards and agencies with individuals). We expand upon these services in support of their programs. The authentication services below (see also Just Privacy Act [PA85] extends Canada’s laws [Just03] for further information). that protect the privacy of individuals with respect to the collection, use, and disclosure In order to authenticate themselves prior to of personal information about themselves accessing certain online government held by a federal government institution. services, individuals can obtain an epass, an The Personal Information Protection and online credential issued by the Government Electronic Documents Act (PIPEDA) of Canada (GoC). An epass consists of a [PIPE00] establishes similar rules and while private/public key pair and associated public the Privacy Act, applies only to GoC key certificate. The certificate is indexed by departments and agencies, PIPEDA also a Meaningless But Unique Number applies to provincial governments and the (MBUN) that has no association with the private sector. individual’s identity. On its own, this certificate is anonymous; until which time Notable policies (applying only to the an individual enrols with a government federal government) that affect the delivery program and the MBUN is associated with of e-government services include: the existing government program identifiers Government Security Policy [GSP02], which (such as an individual’s Social Insurance safeguards employees and assets and assures Number – SIN, which is roughly equivalent the continued delivery of services; and the to the US Social Security Number) for the Privacy Impact Assessment Policy [PIA02], individual (at which point the certificate is which prescribes Privacy Impact pseudonymous). Assessments when there are proposals for, and during the design and implementation of The process of establishing this secure programs and services that raise privacy relationship between the individual’s issues. Additionally, the Common Services MBUN and a government program for Policy [CSP] is designed to ensure that online service delivery is composed of the departments and agencies can acquire following steps: responsive, cost-effective support for their • The individual registers in order to program delivery, while the Common Look obtain their epass. No identification is and Feel Standard [CLF00] is designed to required by the individual at this stage. ensure that all Canadians, regardless of • The individual enrols with a government ability, official language, geographic program, involving (where required) location or demographic category, are given o The identification of the equal access to information on GoC web individual to the program (based sites. on shared, secret information between the individual and the 2.2 Canada’s Secure Channel program), Canada’s Secure Channel (SC) is a o The mapping of the MBUN from collection of network infrastructure, the epass certificate to the operations, and security and authentication existing Program Identifier (PID) services supporting the Government On- that identifies the individual Line (GOL) project. While the Secure within the government program. Channel Network (SCNet) supports a secure This mapping is thereafter retained at the program. 75 4th Annual PKI R&D Workshop Pre-Proceedings Upon subsequent authentication to the organizations that have encountered, or government program, the MBUN from the expect to encounter, similar situations. individual’s certificate is mapped to the PID, thereby identifying the individual, and the 3.1 Guiding Principles/Goals resources they can access. In addition to the In delivering government services, there are epass registration, management operations three entities to consider, and hence three such as self-revocation and recovery are also different perspectives from which to judge supported. the quality of service delivery: the individual user, the department and the enterprise (as Since 2002, over 285,000 epasses have been representative of the whole-of-government). issued to individuals. Key epass-enabled The user perspective is to have their access applications include Change of Address with to services unencumbered by technology or the Canada Revenue Agency and filing politics. Therefore, the “user experience” is Records of Employment with Human important. In addition, users are concerned Resources and Skills Development Canada. with ensuring both the security of their information (and their person!) and well as The SC’s authentication services advantage their privacy. Departments are similarly is that beyond offering a solution that concerned with the needs of their users, but supports the protection of individuals’ also want to offer the most effective and privacy, it provides a common solution for efficient solution possible. Cost is always an use by all departments, avoiding the important concern so that re-usable solutions arguably less efficient “siloed solutions” that offer an important advantage to departments. might be built by each department. It is the enterprise perspective in which the needs for the whole-of-government are In further support of privacy, individuals are considered. Effectiveness and efficiency able to obtain one or more epasses (e.g. across all of government is recognized, mapping to a number of different without the sometimes-narrower constraints government programs). It is likely though of departmental budgets or other that individuals will opt for a manageable requirements. Within the Canadian number of epasses, supporting a more government, the enterprise perspective is consistent experience in their authentication upheld by designated central agencies (that to government. Note also that no personal develop government policy) and common information about an individual is service organizations, such as PWGSC, that maintained centrally to support the epass implement common solutions (including the service; personal information about a user is Secure Channel) within the government’s retained within the context of their policy framework. relationship within a program. Throughout the evolution of Secure Channel, there are a number of challenges 3 Meeting the Challenges have arisen from attempting to satisfy these Related to Secure Service perspectives within our legal, policy and business constraints. In the following Delivery subsections we overview a number of these As Canada continues to offer secure online challenges. services to citizens and businesses, a number of issues have been overcome, while some 3.2 Inter-Jurisdictional Issues remain. This section reviews some of our As mentioned earlier, a number of successes, and considers how we might jurisdictions exist within Canada, each with address a number of lingering challenges. It their own legislative and policy framework, is anticipated that this overview will aid and with their own business requirements. 76 4th Annual PKI R&D Workshop Pre-Proceedings Despite these differences, each jurisdiction through another common service or level of government (federal, provincial, organization, or even choosing to reject the and municipal), interacts with the same set idea of an improved government experience of individuals: Canadian citizens and across multiple levels of government. businesses. For example, the federal However, one can also recognize that we are government is responsible for tax collection, now in an environment that may not have the provincial for access to health services been anticipated by legislation and for which and for issuing drivers licenses, while the it is reasonable to investigate legislative municipal is responsible for water and sewer alternatives. In Canada, this option can be services. In addition to public services, achieved through an Order-in-Council individuals also interact with, and obtain (OIC), involving approval by the Governor services from the private sector (e.g. banks). General, Canada’s head of state, and is currently being investigated. The Secure Channel solutions currently support the delivery of federal government Beyond current legislative hurdles, potential services. To support an improved user policy obstacles also exist. For example, in experience, it would be advantageous for the federal government (in support of services to be similarly offered across other consistent user experience), there exist jurisdictions. Of course, such integration of standards supporting a “Common Look and service offerings must be performed within Feel” for government online systems. These the constraints of legislation and policy, standards go so far as to specify the required especially with regard to privacy. presentation format for web pages. However, in a joint federal-provincial As an example, consider the use of a single presentation, provinces have similar, authentication infrastructure for citizens to sometimes conflicting, policies suited to access government services. As with the their own requirements. As the federal current epass solution for federal services, policies apply only to federal departments, users can choose to use one epass across all there is a gap with regards to policies across services, or use separate epasses for any all levels of government; the common look number of services. Although there might and feel standards are likely but one exist some obstacles to such an endeavour example. (e.g. technical, perception), one clear obstacle is found in current legislation. The Therefore, as we endeavour to offer systems common service organization that provides across multiple levels of government, we’ll the Secure Channel services is governed be sure to uncover other areas where a pan- legislatively by the Department of Public jurisdictional policy regime is lacking. Works and Government Services Act (see Section 2.1) In both this legislation and 3.3 Business Registration Issues other policy (for instance, the Common A business transacting with the Government Services Policy (see Section 2.1)), PWGSC of Canada (GoC) typically has a number of is recognized as a “common service government-issued identifiers for its organization” for the Government of dealings with the various departments and Canada, but the legislation limits this programs of the GoC. While the Business authority to offering services only to Number (BN)1, issued by the Canada “departments, boards and agencies.” Thus, Revenue Agency (CRA) to Canadian the Act currently prevents the offering of businesses for tax purposes seems to have services to our provincial counterparts, for the widest coverage, the use of the BN example. beyond tax purposes is currently limited by legislation. As a result, although many There are a number of options for dealing businesses have a government issued BN, with this issue, including offering solutions 77 4th Annual PKI R&D Workshop Pre-Proceedings not all government departments can collect identifier, the solutions are for specific uses, and use the business number for rather than having a definitive identifier that identification purposes in their be consistently used for online transactions. programming. Thus, businesses obtain other Making the BN the sole common identifier identifiers for interacting with the GoC for for business and making its usage more non tax-purposes. This is important to note widespread would entail legislative change when considering that a common identifier either on the part of CRA or other could be used in a common registration departments and provincial jurisdictions. process for access to online government services. Having a single registration Alternatively, an altogether distinct number, number for a business’ transactions with the publicly available and created specifically to GoC would simplify and enhance a be a common identifier for businesses in business’ interactions with the GoC as a their dealings with the GoC, may resolve whole and further enable business-to- this issue. It is likely that legislation would government online transactions. have to be enacted to allow the creation, collection, use and disclosure of this new An ideal scenario for business registration is ubiquitous identifier. That said, it may be that there would be an efficient way of simpler to create a new number than persist identifying businesses once for their in using an identifier that requires legislative dealings with the GoC. Subsequent change to enable its expanded use within the authentication would be simple for both the GoC and in the provinces. Other benefits businesses and the GoC and would be used include that the public could view the for all business-to-government online business number and other businesses could transactions. One may also wonder if an rely on it to verify the legitimacy of other anonymous credential such as an epass entities. could be used for business registration purposes. And although epass meets This very scenario occurred in Australia in privacy requirements that are critical for 1999 when the A New Tax System individuals, the purpose of an identifier for a (Australian Business Number) Act 1999 business is precisely to identify from an came into force. The act created the authoritative source that a business is Australian Business Number (ABN)2, which legitimate. In addition, with businesses, is related to, but distinct from a businesses’ individual enrolments may not be necessary tax file number and is used when dealing as they are currently with citizens in order to with the Australian Tax Office, other maintain the information silos. government agencies, and when supplying Presently, CRA uses the BN to identify its goods and services to other businesses. business clients and departments including Industry Canada, PWGSC and Statistics The absence of a persistent identifier for Canada, and the provinces of British businesses dealing with the Government of Columbia, Manitoba, New Brunswick, Nova Canada hinders the seamless development of Scotia and Ontario are using the BN for online business-to-government transactions business identification in varying ways. because departments must individually These departments and provinces were able collect similar identifying information from to adopt the BN as a common identifier the same business when this information because they changed their legislation to could be collected once and then shared and allow the use of the BN for this purpose and re-used by other GoC departments. Having a signed memoranda of understanding with common identifier, supported by a central, CRA to use it. This business registration searchable business registry would solution only partially fulfils the need for a streamline the registration process for online single registration number, because even services, allow government departments to though the BN is used as a common leverage the work of others while presenting 78 4th Annual PKI R&D Workshop Pre-Proceedings a single-window to business interacting with the GoC. While the issue of determining a The scenario described above allows the common identifier for online business programs offering the service to identify authentication with the GoC has not been individuals to the level of assurance it resolved, “catalytic projects” that are part of wishes to have and it also keeps the Canada’s GOL initiative are addressing information provided for enrolment in a elements of the problem. For instance, the program-specific silo. Registration for, and purpose of the Common Business maintenance of, the credential can be Authentication catalytic project is to centrally managed (as no personal implement a common authentication service information is collected) offering significant for businesses and individuals in dealing benefit. However, to the individual who may with government [SCF04]. Providing assume that GoC departments already share tombstone information once, the business this information, separate program would then be authenticated once for enrolments may lessen the quality of the multiple services and while having a view of individual’s experience. In other words, a all government transactions. pleasant, non-repetitive experience presupposes either a shared, central While the Canada Revenue Agency BN repository of information, or an information need not become the common identifier for exchange facility in which the individual businesses, it would be advantageous to could decide to share enrolment information make a publicly available business identifier across government programs. As it stands mandated by legislation for use by the entire now, an individual has to authenticate Government of Canada. As in Australia her/himself for each epass enabled services with its ABN, this business identifier would despite being able to register for only one then be the foundation for authenticating the epass. Due in part to legislative and business entity transacting with the GoC. political hurdles, there is no central Furthermore, it could also become an authentication facility for users and identifier used among businesses, and the departments cannot use another service’s public in verifying the legitimacy of a authentication for its own. In the following business entity. paragraphs, we examine the feasibility of two other options. 3.4 Citizen Enrolment Issues When a citizen chooses to use the GoC Joint Information Exchange Facility epass service to transact online with the The Joint Information Exchange Facility is a GoC, the individual registers for one or any concept that demonstrates how a user can number of epasses through a central choose to share authentication information service.3 But in order to access specific PKI- provided for one service with another. This enabled GoC services, individuals must client controlled sharing of information enrol and identify themselves separately means that the user does not have to re-enter with each government program offering a identity-proofing information so long as it service. This is because privacy policy and can be re-used from a previous enrolment, legislation [PA85] restrict either the central resulting in a faster enrolment process and maintenance of such information, and the an improved user experience. The following sharing of information between government scenario illustrates how this concept would programs. The GoC entities offering the be put into action. The client visits a individual services therefore control their department (Department M) and wishes to “program space” and determine what re-use her authentication that was previously information is required in order for the completed at another department citizen to authenticate him/herself to that (Department D). The client pulls the program. information from the originating department (Department D). Department D prepares the 79 4th Annual PKI R&D Workshop Pre-Proceedings information packet for transmission, elects to pass the information packet onto digitally signing the information packet and the receiving department (Department M). sending it to the client’s browser. The client Thus, by establishing individual consent, can review the information but cannot while retaining other privacy features, the change the information and then the client user experience can be greatly improved. Client reviews and authorizes but cannot change the information Pull info packet into Push the info packet from the browser, signed by the browser, signed by Dept D Dept D to Dept M Dept D Dept M reviews and accepts Dept D’s Dept M authentication procedures during set up (info packet) of the exchange process (info packet) Central Authentication Facility authentications, an assurance level might be Although the Joint Information Exchange assigned to the individual’s profile, and Facility improves the user experience, raised subsequent to successful presentation individual participation is still required to of these shared secrets. As a result, the convey (though not physically enter) their individual registers once and authenticates enrolment information. The purpose of a through the CAF, which shares this Central Authentication Facility (CAF) is to information with departments when the serve as the authentication authority for user individual requests access to specific access to online government services. services. Authenticating individuals on behalf of departments, it could allow users to register While the high-level description given here once for access to the suite of online suggests that technical solutions are readily government services. The following available and straightforward, current scenario illustrates how this concept could legislation would keep it from being be put into action. An individual wishes to operationalised. For instance, the Privacy use two departments’ online services. The Act prevents the collection use and user is directed to the CAF. The CAF disclosure of personal information for collects the individual’s tombstone (e.g. purposes other than those for which it was name, date of birth) and contact information collected. As a result, the simplest way of and requests any additional information as making a CAF happen is that the department appropriate. This then becomes the offering the service would have to individual’s profile. The tombstone and legislatively make it one of its “operating contact information collected by the CAF is programs.” An operating program can be made available to the departments’ defined as a series of functions designed to programs, while for additional assurance, carry out all or part of an entity's operations. the programs may choose to ask for The CAF would then be part of a additional e.g. “shared secret” information department’s line of business, collecting specific to the business of the program, such personal information and authenticating as previously submitted tax information. individuals on behalf other departments Over several program-specific offering online services. 80 4th Annual PKI R&D Workshop Pre-Proceedings User Central Authentication Facility Department Online Service - collects appropriate information Department Online Service - aids in enrolment by sharing info with departments Department Online Service operation will rely heavily on demonstration 3.5 Evidentiary Support for of the environment at the time in question, Electronic Data and more generally, that this environment The admissibility or acceptability of was operated upon using standard protocols electronic data is critical to the success of and procedures. Therefore, in support of our online systems, and therefore critical to evidentiary requirements, sufficient our ability to obtain the purported savings standards need to be defined (and of course and efficiencies. Within the world of PKI, followed). such issues have often been mired in narrow discussions of “non-repudiation.” While While the Canada Evidence Act refers to the ensuring the correctness of technical integrity of “electronic documents”, part 2 solutions is important, we will not obtain our of the 2000 Personal Information Protection goals of supporting electronic data unless and Electronic Documents Act (PIPEDA) the technical solutions fit within the legal, [PIPE00], defines more specific tools policy and business framework for the supporting this integrity, including defining overall online solution in question. And a “secure electronic signature.” As specified while a digital signature is an important, if later in the draft 2004 Secure Electronic not necessary requirement for many Signature Regulations (SESR) [SESR04] applications, a digital signature alone does (which serve as a companion to PIPEDA), a not necessarily provide sufficient evidence. “secure electronic signature […] is a digital If repudiated in a court of law, there is much signature” as constructed using public key information that can contribute to cryptography. The SESR also identify a demonstrating that some action was or was recognition process for a “recognized not performed. The ability to support such Certification Authority” in support of evidentiary needs is as much a question of issuing digital certificates for digital information management and the processes signature production. Though not fully that support this management, and needs to specified at this time, the recognition be driven (at least in part) by the relevant process will rely heavily upon the operating legislation (should it exist). Fortunately, in procedures for CAs as defined in the Canada we have some legislation to help Government of Canada’s Certificate guide the determination of required Policies. evidentiary material. In essence, legislation has provided a first Changes to the Canada Evidence Act step in bridging the legal and technical [CAE04] in 2000 included clauses realms from statutes and regulations to describing the evidence required for “the public key technology. The SESR recognize proof of the integrity of […] electronic the need for a recognition process, and documents” for any “person seeking to additional areas may need to be similarly admit an electronic document as evidence.” addressed. As recognized in the Canada The rules of evidence in this matter weigh Evidence Act (above), further standards will heavily upon being able to demonstrate that help to better support the rules of evidence. “the electronic documents system was For instance, the draft Canadian standard operating properly.” Evidence of proper CGSB (Canadian General Standards Board) 81 4th Annual PKI R&D Workshop Pre-Proceedings 72.34 on “Electronic Records as 4 Concluding Remarks Documentary Evidence,” describes Despite the strides we’ve made in the conditions and practices for good data and development of our e-government solutions, records management which will ensure their we often find ourselves having to justify our evidentiary value and admissibility over selection of PKI. The questions are time. commonly asked by individual departments, and are asked in comparison to the option of Within the model and solutions for Secure a PIN-based SSL solution. Such questions Channel, there are three entities affected by often take one of the following two forms: this legal framework: the Secure Channel operations itself, participating departments, 1. Why should we use a common PKI and the user (citizens and businesses). Each solution instead of developing and has a role and responsibility in ensuring the using our own solution, either with confidentiality and integrity of a PKI or with PIN-SSL? Government On-Line transaction and 2. Why is a PKI solution better than a ensuring that sufficient evidence is collected PIN-SSL solution? with regard to such transactions. The argument for a common solution, versus With regard to the operations of Secure individual department solutions, is often tied Channel, as with any other large to the principle of whether cost savings can infrastructure, there are practical concerns be achieved by building and re-using a regarding what information (records and single solution across multiple logs) needs to be retained, and for how long, organizations. When done properly, this in support of evidentiary requirements. The option has the potential for great savings, retention duration will often relate to and also delegates many issues related to departmental requirements for evidence. managing a solution (e.g. software updates) Work is proceeding in this area, though to the common service provider. However, current evidential areas where standard the benefit of improved user experience processes are described and evidence of should not be overlooked. To many assessments exist include the PKI Certificate citizens, departmental distinctions are often Policies (CPs) and Certificate Practice irrelevant. At least from the point of view of Statements (CPS), the results of Secure their experience, they often just want to Channel Certification and Accreditation, obtain service from “the government,” as design documentation, routine assessments opposed to a particular department. (e.g. ensuring proper CA operation), and numerous audit logs relating to key events With regards to comparisons to PIN-SSL, and for day-to-day operations. the bottom line is that comparisons are often apples-to-oranges, with our established PKI- We are well on our way past the question of based solution, adapted to the policy and non-repudiation, and considering solutions legal regimes of government, compared to to the broader questions of evidentiary some PIN-SSL solution. While a PIN-SSL support, with the legal and business solution could be well implemented, with framework provided with our Government additional functionality and security On-Line solution. It is likely that many of features, there are also a number of poor, ill- the evidentiary requirements are refined defined implementations. However, our through case law, though as in most fundamental needs have always been jurisdictions around the world, we have not consistent, including requirements for yet had sufficient experience with persistent integrity with digital signatures, repudiated digital evidence. persistent confidentiality from end-to-end, support for single sign-on with a single 82 4th Annual PKI R&D Workshop Pre-Proceedings epass, and robust credential management. http://laws.justice.gc.ca/en/p- And our novel variant [Just03] has allowed 38.2/text.html us to overcome, or at least better deal with [GSP02] Treasury Board of Canada, common problems associated with PKI Secretariat, Government [Gut, Gut02]. Security Policy, 2002. Available at With our PKI-based solution, we have thus http://www.tbs- far been able to design and deploy a solution sct.gc.ca/pubs_pol/gospubs/T that fits within the legislative and policy BM_12A/gsp-psg_e.asp framework of the Canadian government, and [Gut] P. Gutmann, “Everything you that has attracted over 285,000 individuals Never Wanted to Know about since 2002. As we move forward, it is most PKI but were Forced to Find often these issues, and not those of Out”; see technology, that present us with hurdles. The http://www.cs.auckland.ac.nz/ issues we identified in the previous section: ~pgut001/pubs/pkitutorial.pdf inter-jurisdictional considerations, business [Gut02] P. Gutmann, “PKI: It’s Not registration, enrolment, and evidentiary Dead, Just Resting”, IEEE support for non-repudiation, attest to the Computer, August 2002; see complexity of assuring secure e-government http://www.cs.auckland.ac.nz/ service delivery in Canada. These and other ~pgut001/pubs/notdead.pdf challenges are not insurmountable, and [Just03] M. Just, “An Overview of indeed the possible solutions we offered Public Key Certificate may contribute to making an already world- Support for Canada's renowned solution even more innovative. Government On-Line (GOL) Initiative”, in Proceedings of 5 References 2nd Annual PKI Research Workshop, April 2003. [PA85] Department of Justice – [CAE04] Department of Justice – Canada, Privacy Act, 1985. Canada, Canada Evidence Available at Act, 1985. Available at http://laws.justice.gc.ca/en/p- http://laws.justice.gc.ca/en/C- 21/text.html 5/15974.html [PIA02] Treasury Board of Canada, [CLF00] Treasury Board of Canada, Secretariat, Privacy Impact Secretariat, Common Look and Assessment Policy, 2002. Feel – Background 2000. Available at Available at http://www.cio- http://www.tbs- dpi.gc.ca/clf-nsi/back- sct.gc.ca/pubs_pol/ciopubs/pi cont_e.asp a-pefr/paip-pefr_e.asp [CSP] Treasury Board of Canada, [PIPE00] Department of Justice – Secretariat, Common Services Canada, Personal Information Policy. Available at Protection and Electronic http://www.tbs- Documents Act, 2000. sct.gc.ca/Pubs_pol/dcgpubs/T Available at B_93/CSP_e.asp http://laws.justice.gc.ca/en/p- [DPW86] Department of Justice – 8.6/text.html Canada, Department of Public [SCF04] B. Watkins, “Secure Channel Works and Government Future”, presentation to Services Act, 1986. Available GTEC Special Forum – at Security, October 20, 2004. 83 4th Annual PKI R&D Workshop Pre-Proceedings [SESR04] Secure Electronic Signature account a business may have. http://www.cra- arc.gc.ca/E/pub/tg/rc2/rc2eq.html#P72_2512 Regulations, draft, Canada Gazette Part I, 2004. 2 The Australian Business Number (ABN) is a unique 11 Available at digit identifier issued by the Australian Tax Office (ATO) to all entities registered in the Australian Business Register. It http://canadagazette.gc.ca/part is used when dealing with the ATO, other government I/2004/20040508/html/regle6- agencies, and when supplying goods and services to other businesses. e.html http://help.abr.gov.au/content.asp?doc=/content/16974.htm& Notes usertype=BC 1 The Business Number (BN) is a 15 character client identification number that consists of a nine digits to identify 3 Here we distinguish between registration – the process of the business and two letters and four digits to identify each obtaining an epass from epass Canada – and enrolment – the action of signing up or applying for a Government of Canada service. 84 4th Annual PKI R&D Workshop Pre-Proceedings The Use of PKCS-12 in the Federal Government The PKCS 12 standard built upon and extended the Tice F. DeYoung, PhD 1993 PKCS 8: Private-Key Information Syntax National Aeronautics and Space Administration Standard [2] by including additional identity information along with private keys and by instituting higher security through public-key privacy and INTRODUCTION integrity modes. The PKCS 8 standard described syntax for private-key information, including a The purpose of this paper is to provide a brief private key for some public-key algorithm and a set description of the history of the Public-Key of attributes, as well as, syntax for encrypted private Cryptography Standard number 12, or PKCS-12, the keys. Personal Information Exchange Syntax, for exporting public key infrastructure (PKI) private keys and The PKCS-12 standard describes a transfer syntax for certificates; to investigate the implications of using personal identity information, including private keys, this mechanism as they apply to the Federal PKI certificates, miscellaneous secrets, and extensions. Policy Authority; and to present a set of conclusions Applications that support this standard will allow a which are not recommendations per se, but are rather user to import, export, and exercise a single set of a list of things to consider before one permits end personal identity information. This standard supports users to export their PKI private keys and certificates direct transfer of personal information under several using PKCS-12. privacy and integrity modes, the most secure of which require the source and destination platforms to have trusted public/private key pairs usable for digital BACKGROUND signatures and encryption, respectively. PKCS 12 permits both software and hardware implementations. Before we describe PKCS 12, we should first Hardware implementations offer physical security in mention what the Public-Key Cryptography tamper-resistant tokens such as smart cards. [1] Standards are. These specifications are produced by RSA Laboratories in cooperation with a number of developers worldwide for the purpose of accelerating FEDERAL PKI POLICY AUTHORITY the deployment of public-key cryptography. The first PKCS was published in 1991. Since then the PKCS The Federal PKI Policy Authority (FPKI-PA), under documents have become widely referenced and the auspices of the Federal Identity and Credentialing implemented. Committee (FICC), is responsible for the policies of the various Federal PKI implementations; the Federal PKI Bridge CA (FBCA), the Common Policy THE PKCS-12 STANDARD Framework CA (CPFCA), the eGovernance CA (eGOVCA) and the Citizen and Commercial Class To understand how PKCS-12 came about, we have to CA (C4A). This paper will only discuss the go back to 1995. At that time all of the encryption relevancy of the FBCA and its concomitant software was proprietary and there was no Certificate Policy to the use of PKCS 12. mechanism for people to securely communicate unless they had the same product. This lack of The Federal Government is required to use interoperability was recognized by a number of cryptographic modules that have been accredited as people. meeting the NIST Federal Information Processing Standard 140 level 2 (FIPS 140-2) accrediting There were several development options that could process [3]. Additionally any entities PKI that want lead to interoperability. First, you could set up a new to cross-certify with the FBCA must follow US application specific certificate authority (CA) to issue Government PKI Cross-Certification Methodology PKI certificates for every user of that application. and Criteria. [4]. Once an entity PKI has completed Second, you could develop application specific plug- this process, they are required to sign a Memorandum ins for every other application. Because each of of Agreement (MOA) with the FPKI-PA, which lays these options leads to unnecessary complexity and/or out the rights and responsibilities of both parties. expense, the community arrived at the best option; One of the items in every MOA is the requirement they all agreed that a single standard should be dev- that the entity PKI cross-certifying with the FBCA eloped. That standard came to be known as PKCS shall maintain compliance with the requirements in 12, published by RSA Laboratories in 1999. [1] the MOA and shall notify the FPKI-PA if any material changes occur. 85 4th Annual PKI R&D Workshop Pre-Proceedings ISSUES WITH THE USE OF PKCS-12 in the PKI application and when the data is exported using PKCS-12. The FBCA Certificate Policy [5] is silent on the use of PKCS 12, so that its use does not apparently Now things begin to get interesting. While within the violate any of the requirements in the MOA. PKI application, the keys and certificates are However, as we will discuss later, there are issues centrally controlled and managed. However, when associated with private key protection and activation, the PKI data is exported, the PKI applications are which are application specific that must be addressed. now unable to provide this management because they One of the questions that arises is whether or not an have no control of the portable PKCS-12 container, entity must notify the FPKI-PA if it intends to use nor do they control what applications and devices the PKCS 12; another is whether the entity must notify private keys and certificates are imported into. The the FPKI-PA of every application that it intends to end user is the only one who can control things once import the PKI secret keys and certificates into. they have been exported. Therein lies the rub! The There are others, which will be discussed in more end users will have to maintain consistency between detail in the following sections. their keys and certificates that have been exported and those that are still within the PKI application. Exporting the private keys and certificates isn’t the They will have to keep track of updates, key rollover, problem. PKI applications that follow the PKCS-12 what applications and devices they have exported standard keep the exported data in an encrypted state. them to, etc. They are also the only ones responsible To further explain this, let me use an analogy. Let’s for determining if the applications and devices meet assume that the PKI application is equivalent to a the FIPS 140-2 requirements. How can we ensure safe, because the private keys and certificates are that the end users maintain their exported PKI data in maintained securely, in one place and easy to a manner consistent with their CP and CPS and their centrally manage. When the information is exported, FBCA MOA? it is no longer in the safe, but is in a portable lock box, or secure briefcase, which is portable. The This brings us to the next section of this paper, container is protected, so that doesn’t cause a namely the things one should consider before problem. However, the portable container can be allowing end users to use the PKCS-12. used in an insecure fashion if it isn’t carefully controlled. THINGS TO CONSIDER Let me use as an example the FBCA CP Medium Level of Assurance requirements. The FBCA CP First and foremost, you do not want to do anything requires private keys to be protected with FIPS 140-2 that will cause your use of PKCS-12 to violate the accredited devices and applications for cross- level of assurance of your CA and, if you are cross- certification at the Medium Level of Assurance. I certified with the FBCA, you don’t want to use this example because the overwhelming majority jeopardize the MOA requirements you have with the of entities cross-certified with the FBCA and those FPKI-PA; so tread carefully if you do decide to who have applied for cross-certification have been at permit PKCS-12 export of private keys and this level. Furthermore, the Medium Level of certificates. Assurance at the FBCA covers both Levels 3 (software PKI) and 4 (hardware PKI) as outlined in What are the benefits of permitting the use of PKCS- the OMB Guidance on Authentication Levels[6] and 12 mechanism for exporting private keys and the associated NIST Electronic Authentication certificates? One that comes quickly to mind is that Guideline[7]. For this example I am assuming that it permits you to import them into the Blackberry the PKCS 12 exported PKI data is secured in Personal Digital Assistant (PDA) beloved by upper accordance with FIPS 140-2. Therefore, exporting level management in most Federal agencies. These the PKI data from the PKI application (safe) to the devices are ubiquitous throughout the ranks of these PKCS-12 container (secure briefcase) has not Senior Executives who tend to be the least versed in violated the FBCA CP requirements. One of the information technology security issues. We have to FBCA CP requirements is that passwords used to provide them and their data without bothering them unlock access to the private PKI keys must be at least with details or interfering with their ability to 8 characters in length and contain at least one from properly lead their agencies. each of the following categories (upper case, lower case, numbers and special characters). This Blackberries are only the tip of the iceberg when it requirement is easily met when the private key data is comes to PDAs. There will soon be smart phones, 86 4th Annual PKI R&D Workshop Pre-Proceedings other intelligent PDAs and possible Personal Access H. Develop a Supplemental Networks (PAN). The one thing they have in Subscriber Agreement that common is wireless connectivity. Wireless access describes points will rapidly follow and we will have to provide their additional adequate security for these devices using some form responsibilities and notifies of cryptographic mechanism. Having the same them that private keys and certificates for the myriad devices extra training is required. and applications is an efficient way to easily manage this. PKCS-12 gives you that capability. Here are some things you might want to include in the additional training for your users who want to use Now, what can you do to ensure that giving your PKCS-12. Again, this list is for illustrative purposes users this capability doesn’t compromise your only and should not be considered to be all-inclusive: security and thus your level of assurance? First, review your CP and CPS to see if there are any A. Describe their responsibility changes required. Note that if you are operating at for and methods of the High Level of Assurance, you cannot permit the managing use of PKCS-12 export or you will violate your their exported keys and policies. Second, notify the FPKI-PA of your certificates; intention and the steps you will take to ensure that B. Explain that the users can you do not violate your level of assurance. Next, only import their private consider additional procedures and processes for the keys subscribers that will use PKCS-12 export. Here are a and certificates into few suggestions, but his list is far from complete: applications and devices that their A. Put thePKCS-12 users in a PA has approved as meeting separate group; FIPS 140-2 requirements; B. Use a separate OID in their C. Describe the processes and X.509 certificates; procedures to followed for C. More closely audit their exporting and importing usage; their PKI data; D. Require additional training in managing their private keys CONCLUSIONS and in the procedures for exporting and importing As we stated at the beginning, we are providing no them; conclusions or recommendations on the use of E. Require subscribers to obtain PKCS-12; but instead, have briefly discussed some permission from your things to consider before embarking into the brave agency Policy Authority new world of permitting users to export their PKI (PA) before importing their private keys and certificates using the PKCS-12 private keys and certificates export mechanism. into an application or device; F. Develop a list of FIPS 140-2 However, for your information, we at NASA have approved applications and carefully weighed the attractive benefits and the devices that would be the potential dangers of permitting users to export their basis for your PA decisions private keys and certificates and have made the in E.; decision to permit certain users to use PKCS-12. We G. Issue their credentials at the are now implementing some of the above steps to Basic Level of Assurance, ensure that we do not compromise our security. We but are cautiously optimistic that things will proceed only if absolutely necessary smoothly. to maintain cross- certification 87 4th Annual PKI R&D Workshop Pre-Proceedings REFERENCES [1] PKCS 12 v1.0: Personal Information Exchange Syntax, RSA Laboratories, June 24, 1999. [2] PKCS 8: Private-Key Information Syntax Standard, RSA Laboratories, November 1, 1993. [3] Security Requirements for Cryptographic Modules, NIST FIPS 140-2, December 3, 2002. [4] US Government PKI Cross-Certification Methodology and Criteria, March 2003. [5] X.509 Certificate Policy for the Federal Bridge Certification Authority, 27 September 2004. [6] E-Authentication Guidance for Federal Agencies, OMB 04-04, December 16, 2003. [7] Electronic Authentication Guideline, NIST Special Publication 800-63, v. 1.0, June 2004. 88 4th Annual PKI R&D Workshop Pre-Proceedings Secure Access Control with Government Contactless Cards David Engberg CoreStreet, Ltd. One Alewife Center, Suite 200 Cambridge, MA dengberg@corestreet.com Abstract—Government agencies have begun Once your identity is determined, the system must widespread usage of public key technology for answer a second question: “Are you currently allowed information security applications such as secure email, to access this resource?” This question is answered document signing, and secure login. These deployments through a process called authorization or validation. use PKI tokens in the form of contact smart cards with Unlike authentication, which should always yield the private keys protected through a match-on-card second same identity for each person, the result of factor such as a PIN. More recently, the government has authorization may change frequently. This change may begun to standardize card technology for contactless be the result of a change in user privileges (e.g. a physical access. These contactless cards will be capable of promotion), a change in policies, or a change in the symmetric key usage, but will not be able to perform environment (e.g. time of day, etc.). private key operations. They will also typically be limited This document describes techniques and to 1-4kB of read/write data storage. technologies that can be used to perform secure access This paper discusses ways to use digitally signed control using the current generation of government messages to perform strong authentication and contactless cards. This focuses on solutions that will support cards based on ISO 14443 Parts 1-4 [ISO01], authorization using the current generation of contactless smart cards. This will compare different strategies under such as those using Philips’ DESFire chips. These consideration and discuss the security and usability cards comply with NIST’s Government Smart Card Interoperability Specification (GSC-IS) version 2.1, considerations of each. Particular emphasis is placed on techniques to support the use of these cards in inter- Appendix G [SDW+03]. The general techniques agency and offline settings. described in this document should also be applicable to other contactless memory cards, including those with Keywords—contactless, smart cards, biometrics, access other symmetric key schemes (e.g. HID’s iClass). control The techniques described in this document are primarily compared in their ability to permit strong 1 OVERVIEW authentication and authorization within federated There are two questions that must be answered by environments where a single central access control an access control system before permitting access. The system is not possible. This support for federated first question is: “Who are you?” The answer to this access control also leads to the ability to perform question is your identity, which is permanent authentication and authorization in disconnected throughout your life. The process of answering this settings where no communication is available to central question, authentication, must rely on one or more management servers. factors to uniquely determine your identity. These factors are typically divided into three categories: Something you have: E.g. a badge, a metal key or a 2 SECURE CONTACTLESS AUTHENTICATION smart card The process of authentication uses one or more Something you know: E.g. a PIN or a password factors to securely determine the identity of a cardholder. These factors may be fully independent Something you are: E.g. your fingerprint, your iris or (printed photo, contactless card serial number), or may your voice be interconnected (e.g. contact chip PIN and PKI An access control system authenticates these factors applet). An effective authentication factor will to identify each user. Since your identity never uniquely and unambiguously identify a specific changes, the process of authentication should always individual, binding to their universal identifiers. yield the same result, even if the factors used may Different authentication factors also vary in their level change. of protection against modification or duplication. Finally, some factors that may be appropriate in a closed environment with guaranteed network 89 4th Annual PKI R&D Workshop Pre-Proceedings connectivity may not be usable in federated or By implementing ISO 14443 directly, an attacker can disconnected settings. imitate any desired CHUID. Digitally signed CHUIDs The following sections describe various factors that prevent the assembly of arbitrary false identifiers, but may be used with contactless DESFire cards to perform this does not provide any protection against the complete duplication of a valid CHUID onto another authentication. real or emulated card. 2.1 DESFire card unique identifier (CUID) A stored identification string only represents a basic Every DESFire card is manufactured with a unique assurance factor for authentication. and read-only card unique identifier (CUID), which is made up of a one byte manufacturer code (e.g. Philips: 2.3 Symmetric key authentication 0x04) and a six byte card number that is set by the High-end ISO 14443 cards such as the DESFire manufacturer. Barring a manufacturing error, no two offer strong mutual authentication and over-the-air legitimate DESFire cards should have the same CUID. encryption using symmetric (secret) keys. For The card CUID can be retrieved by any ISO 14443 example, a DESFire application can be configured to only permit access by reader that knows a secret Triple- reader within range of the card. This CUID is read in clear text form during the card selection and anti- DES key that is stored on the card itself. Only readers collision processing, which precedes any other card that know this shared secret key are capable of accessing the application. Separate keys may be actions. enabled for different types of operations (reading, Pro: The serial number is unique and unambiguous. writing, card management) on each card. The UID of a legitimate card cannot be modified. Typically, each card has its own secret key or keys Con: The serial number has no cryptographic or which can be derived using an application “master key” protocol-level protections to prevent an attacker from (which is present on every reader) and some other card- asserting the same serial number as any real card. By specific identifiers (such as the card serial number). implementing ISO 14443 directly, an attacker can This means that each card doesn’t have the same secret imitate any desired CUID. key, so a compromise of one card’s key does not The CUID only represents a basic assurance factor compromise any other cards. On the other hand, every for authentication. reader in a domain must share the same master key(s). Pro: Strong “something you have” factor for 2.2 Stored identification string smaller environments. Key cannot be copied or cloned In addition to the manufacturer’s CUID, it is without access to domain master key. possible to write a more extended identification string Con: Access to master key would compromise into the card memory that represents the cardholder. every card in that domain, permitting duplication of any Example encodings would include a SEIWG-012 string card and access to any reader. Key protection issues [SEIWG02] or a PAIIWG Card Holder Unique significantly constrain the number of places that this Identifier (CHUID) [PAIIWG04]. Under current authentication factor can be used. Cross-domain proposals, this string would be written to the card in a authentication in federated environments is largely known location where it would be generally available in impractical, particularly in disconnected environments a “read-only” mode. due to master key management issues. These identification strings can contain a larger Symmetric keys on cards represent a high assurance amount of unique identification such as organizational factor for authentication in closed environments, but are affiliation and unique personnel identification number not secure for use in inter-agency or disconnected within that organization. environments. A digital signature on the CHUID by a trusted authority can be used to prevent the forgery of modified 2.4 Raw biometric templates CHUIDs. Some deployments of contactless storage cards such Pro: For legitimate cards issued by the government, as DESFire use biometric templates to perform a stored identification string such as a SEIWG-012 authentication using a “something you are” offers a unique identifier that also includes affiliation authentication factor. They do this by storing a raw information for cross-organizational interoperability. biometric template in the card storage area in a read- This string cannot be modified on a valid card without only form. This template can be read off the card and access to the issuer’s master key. compared against a user to help confirm the identity of the user. Con: The stored identifiers are not strongly bound to either the cardholder or the physical card, so they This template can be represented using an older may be easily duplicated or imitated onto another card. proprietary scheme, or could use forthcoming standard 90 4th Annual PKI R&D Workshop Pre-Proceedings representations defined under ISO/IEC 19794 [ISO04] template(s) and the card itself. As long as the CUID is or INCITS 377+ [INCITS04]. treated as the primary identifier for the user, this Pro: The biometric is tightly bound to the user. provides protection against the transfer of identity to other cards. Con: The biometric is not bound to the card or any identifying serial number, so it may be trivially copied Pro: Adding the card’s CUID into the signed to another card or emulator. This does not offer a interchange file provides a strong binding to a unique identifier which mitigates against copying templates useful identification factor in inter-agency or disconnected environments. The lack of any between cards. cryptographic protection would allow any biometric to Con: The CUID identifier may not be a sufficient be presented from a card. reference ID for interoperability, since the CUID may Raw biometric templates constitute a low assurance not be securely known by other entities. This identifier is also not tied into the digital identity represented on factor due to their lack of strong binding and copy protection. the contact half of the card. As in Error! Reference source not found., above, this representation will be expensive in either IO times or memory if more than 2.5 Signed biometric interchange files one biometric template is stored on the card. Rather than storing raw biometric templates on cards, some groups have promoted the storage of one or Adding the external CUID into the signed message more biometric templates on the contactless card with a provides a high assurance authentication factor. digital signature to protect them from modification. These files would typically be written using a 2.7 Signed biometric templates with card ID and standardized signed interchange format such as CBEFF certificate binding [PDR+01] or X9.84-2003 [ANSI03]. To provide a stronger binding to the user’s overall Pro: The basic representations in these standards digital identity, it would be straightforward to extend provide a digital signature around the biometric the logical scheme proposed by the Interagency template, which prevents the creation of arbitrary Advisory Board Data Model Task Force to bind the templates for non-registered users. biometric template to both the card (via CUID) and the user’s more general digital identifier [IAB04]. This Con: Standard CBEFF and X9.84 do not provide could be done by including the relevant serial number strong binding to the card or any identification factors. and issuer information from the cardholder’s The biometric template for any registered user can be Identification digital certificate. This would provide copied to another real or emulated card, which provides binding to a universal unique identifier which would be no protection against duplication. Once a user has been strongly represented on both the contact and contactless registered (so they have a signed biometric template), interfaces. they can reuse the generated interchange file indefinitely. In addition, if the card contains more than The stored biometrics could be bundled together one biometric template, the reader must retrieve all of with this identifying information and bound using a the biometric values (the entire CBEFF) before single digital signature, as shown in Figure 1, below. signature validation can be performed, which will negatively impact transfer speeds for the user. If each biometric template were split into a separate signed file, the time to retrieve one template would be reduced, but the total storage requirement would increase significantly due to the overhead from the interchange file format (dozens of bytes) and the digital signature (approximately150 bytes for RSA-1024). Simple signed biometrics provide only basic assurance for interoperable and disconnected environments. 2.6 Signed biometric interchange files with card ID binding Groups such as the Interagency Advisory Board task force are considering extending biometric interchange formats such as CBEFF to include the card serial number (CUID) in the signed CBEFF body to provide a stronger binding between the biometric 91 4th Annual PKI R&D Workshop Pre-Proceedings could be as simple as adding a certificate identifier field into the IAB proposal. Format metadata Alternately, a different encoding could be used. For Card serial number (CUID) example, an X.509 Attribute Certificate [ISO01b] Identity PKI certificate ID would provide a signed, extensible data format that (Issuer ID, cert serial uniquely binds the cardholder’s identity certificate to one or more biometric templates, the CUID, and any other issuer-defined fields as needed. This would offer Biometric metadata #1 compatibility with existing standards and encodings Biometric template #1 with greater future flexibility. Pro: Binding the biometric to the card’s CUID and the user’s cert ID provides a mapping that ties the biometric, the card, and the high-level digital identity of Biometric metadata #2 the user. This also permits a unified approach to identity management and validation, since the cert ID Biometric template #2 can serve as a universal identifier for all transactions. This could allow inter-agency identification through a federated identity instead of relying on pre-registration. … Con: If more than one biometric template is stored on the card, then this scheme will be either inefficient Digital signature in data transfer times or storage usage. If one signature encapsulates all templates, then all templates must be Figure 1 transferred before any can be used. This may consume a significant amount of time due to the limited data Alternately, each separate biometric template transfer rates for contactless cards. If, on the other (fingerprints, hand geometry, iris scans) could be stored hand, each template is put into a separate digitally in a separate digitally signed format that is bound to the signed file, then the retrieval of one template is card and user, as shown in Figure 2, below. efficient, but a significant portion of the limited memory capacity of the card will be wasted with redundant data and extra digital signatures. With either representation, digitally signed Format metadata biometrics bound to cert and card IDs represent a high Card serial number Format metadata assurance authentication factor. (CUID) Card serial number 2.8 Signed biometric references with card and cert (CUID) ID binding Issuer PKI cert ID (Issuer ID, cert serial As an optimization to the bound biometric templates number) Issuer PKI cert ID described in 2.7, above, CoreStreet believes that the (Issuer ID, cert serial data storage and bandwidth aspects of signed, bound number) templates can be reconciled by signing secure Biometric references to biometric templates rather than the metadata #1 templates themselves. Biometric Biometric metadata #2 Under this scheme, a digitally signed authentication template #1 file (e.g. Attribute Certificate) would be placed onto the Biometric card. Like the previous architecture, this message template #2 would bind together the card CUID, the cardholder’s Digital signature identity cert ID, and biometric information. However, Digital signature rather than storing the entire biometric templates within the signed authentication file, this scheme would only store a one-way secure hash of each biometric template, Figure 2 as shown in Figure 3, below. This logical representation could be expressed through a CBEFF Patron format in the same manner as the IAB’s proposed data format. This representation 92 4th Annual PKI R&D Workshop Pre-Proceedings Biometric Using this scheme, a reader capable of Format metadata metadata #1 authentication using a particular biometric technology (e.g. Iris scan) could initially read File #0 to retrieve the Card serial number Biometric signed master authentication file. This would contain (CUID) template #1 strong binding to the card (which would be verified against the retrieved CUID) and the user’s digital Issuer PKI cert ID identity (attribute certificate). This initial file would be (Issuer ID, cert serial relatively small (200-300 bytes) since it does not number) Biometric contain any of the biometrics. metadata #2 Biometric #1 type & Biometric After reading and verifying the authentication master file, the reader could determine that the desired hash template #2 template type (iris template) is located in File #3. This Biometric #2 type & template could be retrieved without touching any of the hash other biometric templates on the card. Its integrity Biometric #3 type & Biometric could be confirmed by hashing its bytes and comparing hash metadata #3 against the master authentication file. … Biometric Pro: Permits strong authentication in federated and template #3 disconnected environments with minimum of wasted Digital signature data and communication. Optimal scheme when multiple independent biometrics are represented on the Figure 3 card. Con: Small storage overhead (~30 bytes) if only a Using this scheme, the card stores a single single biometric template is stored on the card. Data authentication file, with a single copy of the binding model and representation not defined by existing information and the digital signature. For each standard (e.g. CBEFF). biometric template on the card, this authentication file will contain a indicator of type (e.g. INCITS 377 Use of this type of strongly bound signed biometric Fingerprint Minutiae template) and a one-way secure represents a high assurance authentication factor. hash of that particular biometric file. This would only add around 30 bytes per biometric to the base 2.9 Contactless PKI authentication file. For comparison, it must be noted that cards are currently available that can perform asymmetric The biometrics themselves would be each stored in operations on a contactless (ISO 14443) interface. For a separate file on the card. Each biometric would be example, Oberthur currently distributes FIPS-certified unsigned. However, the single signature on the contactless cards based on Philips chips that can authentication file could be used to confirm the perform RSA operations on both contact and integrity of any of the referenced biometrics. We contactless interfaces. While this technology has not would recommend that the individual biometric been selected for the current generation of government templates be stored in separate card files in the same smart cards, the protocol-level compatibility could order that they are represented in the authentication file. permit a simple transition in the future. For example, an application could be provisioned on the DESFire card with the following files: These contactless capabilities could be enabled by either linking the contactless antenna to the contact chip (dual-interface) or else by integrating an independent File ID: 0 Signed authentication file (e.g. Attribute contactless chip (combo card). Certificate) Pro: Provides strong authentication without requiring access to biometric information. File ID: 1 Biometric template file #1: Finger #1 minutiae Con: Dual-interface cards may introduce security and privacy concerns if access becomes available to File ID: 2 Biometric template file #2: Finger #2 sensitive applications on the contact chip. Combo cards minutiae may significantly increase per-card costs over simpler symmetric chips like DESFire. File ID: 3 Biometric template file #3: Iris template Use of contactless cards with private key … … capabilities would represent a high assurance factor. 93 4th Annual PKI R&D Workshop Pre-Proceedings 3 BIOMETRIC CONSIDERATIONS The ability of an attacker to forge a biometric authentication factor depends on the countermeasures The previous descriptions of biometric-based provided by the biometric vendors. For example, authentication assume the existence of ideal biometric advanced fingerprint sensors attempt to detect the algorithms that are acceptable for widespread usage. difference between live fingers and duplicates using For real-world applications, the use of biometric proprietary detection of temperature, moisture, templates may introduce several issues. conductivity, etc. 3.1 Privacy 3.3 Interoperability The collection of biometric information by In spite of ongoing efforts to standardize biometric government agencies can raise concerns that this data templates and sensors, unacceptable incompatibilities may be misused. For example, a database containing may exist between templates and algorithms from the fingerprint templates of all government-affiliated multiple vendors. It is believed that these individuals could be a tempting target for someone interoperability issues will improve as the relevant wishing to establish the owner of a latent fingerprint. standards are finalized, but this may not provide an Similarly, a database of face images could be searched adequate solution for the current generation of cards. to identify lawful protestors. This may require a fallback from efficient This concern for biometric searches (1-to-N) may representations (e.g. fingerprint minutiae) to bulkier be lessened by an approach that only stores biometric forms (e.g. full fingerprint images) that may exceed the information on user cards. The schemes, above, would storage capacity of contactless cards. permit an attacker up to a meter away from a user to silently pull the user’s biometric templates along with the user’s serial number(s). 4 SECURE CONTACTLESS AUTHORIZATION This attack should be contrasted with the ability of a If contactless authentication is performed using only nearby attacker to gather equivalent data through more factors that are bound to the card’s serial number (CUID) or domain-specific authentication string (e.g. prosaic means. For example, a facial image on the card would be more difficult to capture than a snapshot from CHUID), then any solutions to validate and authorize a digital camera. A fingerprint template would be no the cardholder will be inherently limited to the physical access domain, since there is no strong tie to the digital easier to retrieve than a latent fingerprint left by the cardholder. identity represented on the contact interface of the card. If, however, the authentication is tightly bound to More importantly, the biometrics on the card should not be tied to identifying biographic information. The the cardholder’s digital identity, as represented by their schemes, above, recommend binding the biometrics identification public key certificate, then the same unique identifier can be used for both contactless only to arbitrary serial numbers, not biographic identifiers such as name or social security number. physical access and contact PKI transactions. This means that a passive reader in the Pentagon Metro This property permits a unified approach to securely station may be able to silently retrieve a large number managing the privileges and revocation of a cardholder. of government fingerprint templates, but these would be For example, OCSP [MAM+99] or CRLs could be used no more useful for building an identification database to determine whether the cardholder has been revoked, than random fingerprints from the subway’s poles. and this same scheme would be usable for both physical and logical access. Privileges could be securely 3.2 Forgery delivered for use in both physical and network Another possible concern with the use of biometric environments. templates is the potential for an attacker to use the template as a basis for a forged biometric that could fool some sensors. For example, a facial image suitable for face recognition could also be used to create a printed image capable of fooling some face recognition systems. This property of biometrics also prevents the effective revocation of the biometric factor if it is ever compromised. Unlike a private key, which can be revoked and replaced, a duplicated finger cannot be comfortably discarded. 94 4th Annual PKI R&D Workshop Pre-Proceedings OCSP Response Cert ID: 1234 Status: Valid Expires: 1/7/05 17:00 Contactless authentication Contact-chip authentication (bound biometrics) (X.509 digital certificate) Format metadata Cert issuer Card serial number Cert subject Identity PKI certificate ID Serial number (Issuer ID, cert serial number) Public key Biometric #1 type & hash Extensions Biometric #2 type & hash … … Digital signature Digital signature Figure 4 Each authorization message is strongly bound to the 4.1 Unified authorization messages cardholder’s digital identity by including the Figure 4 shows the same authorization message, in cardholder’s identity certificate ID within the signed the form of a digitally signed OCSP Response, being message body. Any reader can inspect the used for physical and logical access for the same card. authorization message to confirm its integrity and This authorization message could be represented using timeliness, and then use the validation and privilege any other desired standard such as a digitally signed information to grant access. SAML assertion [OASIS02], an X.509 attribute certificate, etc. Rather than proscribe a particular authorization message format for the entire government to permit This scheme also provides a smooth migration to inter-agency and offline authorization, CoreStreet dual-interface cards where the same general recommends that the government permit the allocation applications would be available though either the of a reusable “authorization container” on the contact or contactless (T=CL) interfaces. By logically contactless card that may be used to store any identifying users using their cert ID today in a DESFire authorization information used within an individual contactless environment, there is an easier migration to organization. a future when the public key identity applet itself is available for secure asymmetric challenge-response Figure 5 shows the structure of a possible general authentication. authorization container on a contactless DESFire card. 4.2 Offline authorization If authentication factors such as signed, bound biometrics are available on the contactless interface, then strong authentication can be performed in offline settings without any access to an online directory. Similarly, secure authorization can also be performed in offline settings by storing signed authorization messages on the contactless interface. 95 4th Annual PKI R&D Workshop Pre-Proceedings 5 CONCLUSIONS ... other applications … The current generation of contactless identification cards have limitations which make it difficult to provide AID strong authentication for large, federated environments. F51230: Authorization Application Various approaches achieve different choices to balance scalability, security, and performance for physical Authorization message file access control. If strong authentication is required for federated OCSP Response environments, we believe that this can only be achieved using either strongly bound biometrics or contactless Cert ID: 1234 public key support. Unfortunately, these approaches Status: Valid may run into issues of privacy and cost which could prevent them from being adopted. Lower-assurance Expires: 1/7/05 17:00 alternatives may result in a higher risk of compromise through cloned identification credentials. Strong federated authorization, on the other hand, may be possible under either scheme through the use of signed authorization messages for access control. Optional additional files … 6 REFERENCES [ANSI03] American National Standards Institute. ... other applications … Biometric Information Management and Figure 5 Security for the Financial Services Industry. ANSI X9.84-2003. 2003. For example, the inter-agency standards bodies [INCITS04] InterNational Committee for Information could define an application identifier (AID) and file Technology Standards. Information number which has free read/write access. A cardholder Technology – Finger Pattern Based with this applet could arrive at one agency, which may Interchange Format. January 2004. put a signed OCSP response onto her card to indicate validity and privileges. Offline readers in that agency [IAB04] Interagency Advisory Board (IAB) Data would retrieve this OCSP message and use it to Model Task Force. IAB Data Model determine access privileges. At a second agency, the Task Force Report v0.6 (Draft). October cardholder’s card may be loaded with a signed SAML 2004. assertion of the user’s privileges, which would be used [ISO01] International Standards Organization. to determine access at offline readers within that second Identification cards – Contactless agency. integrated circuit(s) cards – Proximity The three important characteristics of this cards – Parts 1-4. ISO/IEC 14443. authorization container are: 2000-2001. • Standardized location on the card (3-byte AID on [ISO01b] International Standards Organization. DESFire cards) Information technology – Open Systems Interconnection – The Directory: Public- • Unrestricted read/write access key and attribute certificate frameworks. • Sufficient space for signed data (ideally, at least ISO/IEC 9594-8. August 2001. 1kB) [ISO04] International Standards Organization. In Figure 5, the authorization message file is Information technology -- Biometric data currently holding an authorization message in the form interchange formats. ISO 19794. Under of an OCSP Response, but the authorization message development, 2004. could be any digitally protected format that is strongly [MAM+99] M. Myers, R. Ankney, A. Malpani, S. bound to the identification credential. Galperin, C. Adams. X.509 Internet This scheme would permit the greatest flexibility Public Key Infrastructure Online for supporting inter-agency and offline authorization by Certificate Status Protocol – OCSP. allowing each organization to locally specify their IETF RFC 2560. June 1999. chosen representation, while guaranteeing that the card [OASIS02] Organization for the Advancement of hardware in use by different agencies will interoperate. Structured Information Standards 96 4th Annual PKI R&D Workshop Pre-Proceedings (OASIS). Guidelines for using XML Brigitte Wirtz. CBEFF: Common Signatures with the OASIS Security Biometric Exchange File Format. Assertion Markup Language (SAML). NISTIR 6529. January 2001. Draft 02. September 2002. [SDW+03] Teresa Schwarzhoff, Jim Dray, John [PAIIWG04] Government Smart Card Interagency Wack, Eric Dalci, Alan Goldfine, Advisory Board’s Physical Security Michaela Iorga. Government Smart Interagency Interoperability Working Card Interoperability Specification, Group, Technical Implementation Version 2.1. NIST Interagency Report Guidance: Smart Card Enabled 6887. July 2003. Physical Access Control Systems, [SEIWG02] Security Equipment Integration Working Version 2.2. July 2004. Group, US Department of Defense. [PDR+01] Fernando Podio, Jeffrey Dunn, Lawrence Access Control Technologies for the Reinert, Catherine Tilton, Lawrence Common Access Card. April 2004. O’Gorman, M. Paul Collier, Mark Jerde, 97 Identity-Based Encryption with Conventional Public-Key Infrastructure Jon Callas PGP Corporation Palo Alto, California, USA jon@pgp.com 18th February 2005 Abstract This paper proposes an identity-based encryption (IBE) scheme based on traditional public-key cryptographic systems, such as RSA, DSA, Elgamal, etc. This scheme has a number of advantages over other systems. It can rely upon these traditional systems for its security. Since it uses these traditional encryption schemes, it is interoperable with and easily embedded within an existing security system that uses these functions. Additionally, its construction as an on-line system avoids the operational security flaws of IBE systems that allow off-line key generation. 1 Introduction Conceptually, public keys behave a lot like telephone numbers — if I want to call you, I need your telephone number. I don’t need my own number to make calls (I can use a pay phone, for example), I need one to receive them. In a fashion that is analogous to a telephone number, I need your public key to encrypt something so that it is secret to you. Unlike telephone numbers, public keys are far too big for people to remember. Even elliptic curve keys, which are much shorter than the traditional ones are far too large for a person to remember. George Miller’s classic research [MILLER56] done on telephone numbers is that the average person can remember seven give or take two digits. A 160-bit key will be something over 40 digits long (exactly 40 if we use hexadecimal). So memorizing someone’s key the way you memorize their phone number is completely out of the question. Consequently, we need to have some blobs of data that say that a name such as alice@example.com belongs to some key. There is also value in digitally signing the blob so that the receiver has some assurance that the association is accurate. These blobs are certificates. Like any data management problem, certificate management is harder than people would like. This is why in 1984 Adi Shamir suggested the idea of coming up with a crypto scheme in which any string can be a public key [SHAMIR84]. Thus, there is no need to associate a name with a public key, because they’re effectively the same. This is Identity-Based Encryption. 1 While typically we think of IBE systems converting names into public keys, it should be possible to make any arbitrary bit-string, ID ∈ {0, 1}∗, a determinant of a public key in an IBE system. Thus, a name, an email address, or even a binary object such as a picture or sound can be considered equivalent to a public key. Thus, an IBE system can be thought of as a function of the form Ki = IBE(IDi ) that produces keys from arbitrary bit strings that we call identities, without loss of generality. 2 Overview IBE can also be thought of as an Attribute-Based Enrollment mechanism. Its goal is to reduce the overhead required to bring an entity into the system. Thus, we take some attribute of the entity and use that as a functional equivalent to a public key. In the past, work on IBE has been mathematical. It has developed a new public-key cryptosystem that has as a part of its key creation some arbitrary bitstring that is the identity. We examine this past work and look at how they are put together, as well as the limitations on these previous systems. Next, we construct a framework for an IBE system that satisfies the basic goals of IBE — that this attribute of an entity, its so-called identity is equivalent to a public key — and uses a parallel structure. However, this new framework can construct key pairs that are of a familiar cryptosystem such as RSA, rather than requiring its users to adopt a new public key algorithm. This construction also differs from present IBE systems in that it does not allow off-line generation of keys, but we also note that off-line generation has security drawbacks as well as advantages. However, on-line generation also permits a hybrid PKI that has both traditional and identity-based aspects in the same infrastructure. Lastly, we look at open and unsolved problems that surround IBE systems in general, including this one. All IBE systems created so far have a set of limitations as well as characteristics that are not yet solved. They do not remove the utility or desirability of IBE, but do limit where it can be effectively deployed. 3 Components of IBE An IBE system contains four basic components in its construction: 1. System Setup: IBE systems rely upon a trusted central authority that manages the parameters with which keys are created. This authority is called the Private Key Generator or PKG. The PKG creates its parameters, including a master secret Kpkg from which private keys are created. 2. Encryption: When Bob wishes to encrypt a message to Alice, he encrypts the message to her by computing or obtaining the public key, PAlice , and then encrypting a plaintext message M with PAlice to obtain ciphertext C. 2 3. Key Extraction: When Alice wishes to decrypt the message C that was encrypted to her name, she authenticates herself to the PKG and obtains the secret key SAlice that she uses to decrypt messages. 4. Decryption: When Alice has C and SAlice , she decrypts C to obtain the plaintext message M. No matter the specific parameters or requirements of the system, these functional aspects are always present in IBE systems as their defining components. 4 Previous Work Shamir’s original system was based upon RSA encryption and is a signature-only system. Shamir was unable to extend it to an encryption system. Between 1984 and 2001, a number of IBE systems were created, but they all had limitations, such as requiring that users of the system not collude, or requiring large amounts of computation on the part of the PKG. In 2001, two new proposals were published, improving on previous work. Clifford Cocks created a scheme based upon quadratic residues [COCKS01]. Cocks’s system encrypts bit-by-bit, and requires expansion of the message; for a 1024-bit modulus and a 128-bit bulk encryption key, 16K of data must be transfered. With modern networks, this is a completely acceptable overhead1 . Dan Boneh and Matt Franklin created a scheme based upon Weil Pairings [BF01]. Pairing-based systems use bilinear maps between groups to establish a relationship whereby hashes of the identity create the encryption scheme. Boneh-Franklin IBE has had further work [BB04] and is an active area of research. Horwitz and Lynn [HL02], Gentry and Silverberg [GS02] improved upon performance characteristics of a Boneh-Franklin PKG by extending IBE systems to Hierarchical IBE (HIBE). Their work is important particularly because of its attention to the practical details of constructing a scalable PKG. Gentry also described Certificate-Based Encryption (CBE) that uses an IBE system with certificates to create a hybrid approach [GENTRY03] that essentially makes the “identity” not be a name, but a well-defined certificate. In a conceptually related approach, Al-Riyami and Paterson have their Certificateless Public Key Cryptography [AY03]. Benoît Libert and Jean-Jacques Quisquater also created an identity-based signcryption scheme based on pairings [LQ03]. These signcryption schemes combine both aspects into one operation. There is other somewhat related work on combining signing and encryption as well such as [ZHENG97]. 1 Other discussions of IBE have characterized this expansion as an unacceptable overhead. Debating how much expansion is tolerable is orthogonal to this paper, but I feel it necessary to explicitly state that I find acceptable what previous authors find unacceptable. Networks continually get faster. Many messages are small enough that other overhead they already have to deal with (like conversion to HTML) also expand them. In the case where the message is large, clever software engineering could use compression and efficient bulk encryption to make this no worse than other message bloat. 3 5 Limitations on Previous Work All of the existing IBE systems have their own limitations. Shamir’s system signed but did not encrypt. Cocks’s system needs care to avoid an adaptive chosen ciphertext attack. It is also inefficient, but still efficient enough for use on reasonable communications paths. While others have proofs of security, there is a notoriously poor relationship between proofs of security and actual system security. Security proofs can show where a system is safe, but not protect against new assumptions that an adversary can bring to bear against the system nor against uses of a system that its creators did not think of which may be outside of the scope of the original threat model. Still other subtle problems have shown up on other systems, such as the ability in early HIBE systems for colluding users to determine the PKG’s master key. With the exception of Shamir’s system, IBE systems rely on new public-key cryptosystems, most often Weil pairing. Consequently, they are not compatible with existing systems that use RSA, Elgamal, or DSA. This limits their practical application, since there are many existing systems built upon these cryptosystems. Also, experience and comfort with the security of these established systems is high. A key advantage that Shamir’s system has over all those that follow it is that it was based on established public key cryptography, and thus (had it been successful in being both a signing and encrypting system) interoperable with non-IBE systems. Had Shamir’s system been successful at encrypting, an RSA-based IBE system would likely be the dominant IBE system today, if for no other reason than its interoperability with deployed systems. This is an important observation — if we can construct an IBE system that uses traditional, integer-based, public key cryptography, the barriers to adoption of IBE systems might be lowered. The value that IBE has can be fully realized if it can be made to work with these established systems. Furthermore, this system has the advantage that it can rely on twenty years of mathematical and operational familiarity with these traditional public-key cryptosystems. 6 Security Parameters of the Off-Line and On-Line worlds Previous IBE systems have as a desirable property that they support off-line generation of keys. That is to say, Bob receives key-generation parameters from the PKG once, and then can generate an arbitrary number of public keys. While off-line key generation is desirable, it is not without its own security consequences. 6.1 Advantages of Off-Line Generation Off-line generation is ideal in an off-line environment. If communication with the PKG is slow, expensive, or unreliable, then off-line generation is a huge advantage to its users. They need only one interaction with a given PKG to be able to do all needed work with that server. This advantage becomes less, however, as communication with a PKG becomes cheaper, easier, and faster. One some level, off-line key generation is nothing more than a key server that is an algorithm instead of a database. This is an advantage when databases are static and expensive, but not when databases are cheap and fast. In an environment where the contents of the database 4 are dynamically changing, a database change is not only an algorithm change, but an algorithm change that must be propagated to all clients of the PKG. 6.2 Disadvantages of Off-Line Generation Oftentimes, the strengths of a system are also its weaknesses. This is also true with off-line generation. Off-line generation makes key generation easy not only for legitimate users of of the system but for illegitimate ones. An issue that PKIs must consider in their design is that of a Directory Harvest Attack, in which senders of unwanted advertisements or outright fraudulent confidence games use the directory as a way to discover information paths into the system. Off-line generation of keys allows spammers and other attackers to to pre-generate email attacks in their own system or create a distributed system for encrypted attacks. These attacks are not an issue in off-line systems. Off-line generation has the disadvantage that there is complete transparency in the directory, since the directory is an algorithm. Anyone with that algorithm has all possible entries in the directory and their public keys, and this can be exploited in side-channel attacks that are not attacks on the cryptographic system per se, but the way the system is used. Off-line generation has as an additional disadvantage increased revocation problems. A conventional PKI must be able to re-issue certificates and handle for revisions in the PKI. An off-line IBE system must not only handle revocation of the certificates themselves but a revocation of the algorithmic parameters that comprise its own PKI. No IBE system before this one has even considered this real-world problem. In fact, the key advantages of this on-line system are that it considers and solves these real-world problems. 6.3 On-Line IBE for the On-Line World Sadly, trends in the real world make the advantages of off-line IBE moot, and turns its disadvantages into outright security problems. There is little need for off-line generation in an on-line world, and the advantages of off-line generation benefit attackers more than defenders. Nonetheless, IBE has desirable characteristics. The core IBE concept, that there is an equivalence relationship between bit-strings and keys has appeal. Designing an IBE system that has the advantages of name-to-key mapping without the security flaws of off-line key generation can make IBE acceptable to the complex security requirements of the Internet. Furthermore, if we shift the IBE system to an on-line system, we can construct it so that it uses traditional keys. This permits an IBE system to be embedded within an existing cryptosystem and interoperable with existing systems that use these keys. Not only does this remove adoption issues, but it also simplifies proofs of security; it is trivial to prove that an encryption portion of an IBE system is as secure as RSA if the underlying encryption is RSA. Another advantage is that an on-line system can normalize the identity. It is common for users of an email system to have equivalent identities on the system. For example alice@example.com 5 and asmith@example.com may be the same user, and it is desirable to have only one key. An on-line system can canonicalize identities at runtime. Finally, and perhaps counterintuituvely, this permits IBE keys to be used in certificates. We usually think of IBE as a way to eliminate certificates. However, all keys require standard data structures for transport. Whatever flaws they have, certificates are existing, standard ways to format key material in a way that systems can reliably use them. Objections to certificate-based systems are not objections to the certificates per se, but to the certification process. Without a standard set of transport data structures, IBE proponents must standardize on key transport data structures and convince developers to use those structures as well as the new crypto algorithms and protocols. Using existing certificate systems reduces the Key Extraction problem to an existing problem that has a simple solution, e.g. a lookup in a directory. Combining certificates with IBE is not new to this proposal. Gentry’s CBE combines a form of certificates with Weil pairings. On-line systems are ubiquitous and becoming more available every day. Consequently, the advantage of off-line key generation in an IBE system not only has less value today than it did when Shamir first suggested IBE in 1984, but new attacks turn it into a boon for the attacker of a system. Relaxing the parameters of an IBE system so that Bob is required to ask the PKG for each key is certainly practical, and permits us to exploit these other desirable system features. 7 Constructing IBE to Use Conventional Cryptography It is a goal of this system to describe how to construct an IBE from well-known components that have easily-understood security constraints, including proofs of security. Thus, what follows is actually a adaptive framework for constructing an IBE system that is not bound to a single algorithm and is functional even in the face of security advances such as new attacks on hash functions [BIHAMCHEN04] [JOUX04] [WANG04]. 7.1 System Setup Setting up the PKG consists of the following steps: 1. The PKG selects a master key, Kpkg . This key must be selected with care, as the security of the underlying system can be no more than the security inherent in this key. This key may be a symmetric key, or an asymmetric key. 2. The PKG selects an Identity Digest Function, IDF. This is a pseudo-random bit function of the identity, ID, and Kpkg that gives an Identity Digest Token, IDT such that IDT = IDF(Kpkg , ID). The IDF can be a symmetric-cryptographic function using the Kpkg as some simple secret. For example, it could be a an HMAC, a CBC-MAC, or some other suitable pseudo-random bit function. The IDF may also be an asymmetric-cryptographic function such as RSA, in which case Kpkg might be an appropriately strong RSA key and IDT is thus the result of an 6 RSA encryption of either ID directly or a hash of ID. Note that in this and similar cases, padding must be considered carefully to preserve the needed determinism of the IDF as it establishes a one-to-one correspondence between ID and IDT. Without a one-to-one correspondence, then this is not an IBE system at all. It may be desirable for this selection to be part of the setup; the PKG could be built with a number of options of IDF, one selected at setup time. Regardless of IDF selection, the resultant IDT is a limitation on the security of the IBE keys. If, for example, it were the CBC-MAC of a block cipher with a 64-bit block, then the underlying system has a birthday attack on the IDT that is probably less than the other parameters of the system. Selecting the IDF requires analysis of the overall system lest this be the security bottleneck of the system. 3. The PKG selects a deterministic pseudo-random number generator, RN G that will be seeded with IDT. This RN G is not the same function as IDF as it will in turn be used by a key generation function, Kgen, that generates an IBE key pair. This would be an RSA, DSA, Elgamal, or other key generation function2 . Of course, it itself must be deterministic, as the same key must be generated any time a given identity is put into the system. This construction has advantages beyond the simplicity of being able to use any key type within an IBE system. The security of the system relies on previously-studied components, which provides for easier security analysis. It also implicitly guards against some forms of attacks, such as collusion attacks. Breaking the Kpkg is as hard as breaking known forms of cryptography. So long as a suitable IDF function is selected, the whole Kgen process is as secure as its underlying cryptographic subsystems. 7.2 Key Extraction When the PKG is requested for a key for a given ID, it follows the following process: 1. The PKG produces an IDT, such that IDT = IDF(Kpkg , ID). 2. The PKG seeds RN G with IDT. 3. The PKG generates a key with Kgen(RN G) to produce the appropriate IBE key pair, IKPID . 4. If the PKG has an unauthenticated request for the given ID, then it responds with IKPIDpublic . This happens when Bob asks for Alice’s key. 5. If the PKG has an authenticated request for ID, such as when Alice asks for her own key, then the PKG responds with both IKPIDpublic and IKPIDprivate . At this point, Alice and Bob each have the appropriate piece(s) of a conventional key pair and they use it normally. 2 Without loss of generality, the Kgen function can also be a function such as an elliptic-curve key generator. However, since one of the advantages of this design is that it produces keys that are usable within widely-used systems. When elliptic-curve systems are more widely used, it will be trivial to extend this to an IBE system based on them. 7 4th Annual PKI R&D Workshop Pre-Proceedings 7.3 Encryption and Decryption Encryption and decryption are trivial; they are simply the encryption and decryption functions of the base cryptosystem of the IBE keys. Note that if the cryptosystem is a signature-based cryptosystem such as DSA, it is signing and verification rather than encryption and decryption. 8 Security Limitations As with all IBE systems, there are a number of security limitations of this system. However, in all cases the limitations of this system are no different than for other IBE systems. 8.1 Key Escrow Problem IBE systems are effectively key escrow systems. It is a limitation, if not an outright flaw of IBE that the PKG holds all the parameters needed to generate any key pair, if not the key pair itself. Consequently, Bob can never be completely assured that Alice and only Alice can decrypt a message or created a signature. In the real world this is less of a problem than it is in theory, as the security Alice’s secret key is always bounded by the operational parameters of her key storage. It is undeniable, however, that an RSA key generated on a secure token is going to be more secure than one generated in a PKG. IBE systems, including this one, may be unacceptable for some uses. If there is a legal requirement that Alice’s private half of her signing key be in her possession alone, then no IBE signing system will be acceptable. Boneh and Franklin suggest a partial solution to this problem. In their partial solution, their master key can be split using a secret-sharing system [SHAMIR79]. This has the advantage that no single entity has any of the core secret parameters. An adversary would have to compromise enough members of a set of PKGs to reconstitute the secret. Nonetheless, this is only a partial solution. At some point, the set of PKGs must reconstitute the parameters, and an adversary that sufficiently compromises the appropriate member can still get the parameters. Furthermore, since the members of the PKG set are likely to be close to identical, they are not independent in their security. If an adversary can compromise one member of the set, it is more possible if not likely that the adversary can compromise the whole set. Another solution would be to keep the master parameters in secure hardware, or even secret-shared across a set of pieces of secure hardware. But this adds complexity on top of complexity to the system. In this system, we accept that the IBE parts of this system are by necessity a key escrow system, but note that it can fully interoperate with another other PKI that is not a key escrow system. Furthermore, this system can be integrated with a more secure public key system to provide it with IBE features. For example, the IBE in this system gives a way that keys can be created for roles such as Security Officer or Ombudsman without pre-defining these roles or their owners prior to use. This is another advantage to merging IBE aspects into conventional PKI. Within a given 105 8 4th Annual PKI R&D Workshop Pre-Proceedings PKI, you can have parts of it that are IBE-derived, and parts that are fully-secure, edge-generated public key pairs. Moreover, they all interoperate seamlessly. 8.2 Security of Key Generation The security of the keys generated by the PKG are bounded by the selection of the underlying functions as well as the scale of the PKG. If the PKG is to generate many, many keys, then factors such as the possibility of identity collision have to be taken into account as well. This is not an intractable problem — there are many underlying functions that can be used for components of the PKG that have adequate security parameters for security. It must simply be noted that these are security design factors that are unique to an IBE system. 8.3 Security of Key Extraction When Alice extracts her private key from the PKG, the PKG must deliver it to her securely. There are many ways to do this, including secure network connections such as TLS [TLS]. It also must be packaged securely (and this is another place where existing data structure systems such as certificate standards gain help). This is again, not precisely a security problem but more of where the PKG builders must take care in their delivery system. 9 Open Problems IBE is not yet a mature discipline. There are a number of open problems beyond improving the security of the underlying system that are yet to be solved. Here is a short discussion of some of them. 9.1 Removing Key Escrow All IBE systems, including this one, accept the fact that they are key escrow systems. However, nearly any discussion of IBE includes a class of people who consider the escrow aspect to be a severe flaw. It certainly makes the system brittle, as security of the system relies on non-mathematical security. A real-world PKG must be an un-hackable computer, even if that computer has advanced mathematical techniques such as secret-sharing as an additional bit of armor. It makes the simplicity that IBE gives on one axis be balanced by complexity on another. As cryptographers and systems designers, we have accepted key escrow as a part of the playing field because if we don’t, there’s no IBE. In an academic paper, this is a reasonable assumption, but in the larger world, this assuming key escrow as an implicit part of the system cannot be simply brushed away. This is a large open problem with no good solution. IBE exists for operational simplicity, but has operational complexity as a cost. Removing that cost should be the primary goal of future work, in this author’s opinion. 106 9 9.2 Is it Possible to Eliminate Certificates? The whole raison d’être for IBE is to “solve” the certificate problem. However, this means that IBE assumes that it is possible for a certificate to consist solely of a name and a key. In the real workd, certificates have always been more than a mere binding between a name and a key; they also carry metadata about the name, the key, parameters of use, and even metadata about the metadata. One of the most important bits of metadata about a key is revocation data. If a name is a key, then it is not possible to revoke the key without revoking the name as well. The utility of Alice not having to have a certificate is small if she must revoke her email address if she loses a smart card. Furthermore, telling everyone who has Alice’s email address that they must use her new one (and thus new key) is precisely a key revocation problem with added disadvantages for Alice. Boneh and Franklin [BF01] suggest a clever solution to this situation. In their paper, they suggest that IDAlice not be "alice@hotmail.com" but "alice@hotmail.com || 2004". They even suggest that the PKG can create daily-use keys such as "alice@hotmail.com || February 29, 2004". As elegant as this solution is, it prompts other questions. Once an identity is not simply a name, but is now a name and a date, is it still Identity-Based Encryption? Phrased another way, isn’t "alice@hotmail.com || 2004" merely a different way to code a certificate? Implementing this solution also requires other surrounding standardization that detracts from the essential simplicity of the IBE concept. At this simplest form, you have to standardize on what a date is. This isn’t difficult, but you have to do it. You must also translate malformed dates (perhaps "2 Février 2004" into "02/02/2004:12:00:00.00UTC+0100" which again detracts from the simplicity of IBE, as this is no longer something that a human being can reliably type the way that they can reliably type "alice@hotmail.com". However, this is a problem that can be solve through software, an one where an on-line system has an advantage as it can canonicalize time in a central place, or even round to an internal epoch. Previously in this paper, we discussed the algorithmic revocation problem as well. No IBE system before this one has even considered how the IBE parameters, the IBE algorithm itself, can be revoked. The fact that IBE is brittle in its reliance on central secrets makes this lack a larger open problem. Lastly, there is no means in an identity to express variables within a cryptosystem. There can be no negotiation about acceptable block ciphers, data compression, data MACing, both start and stop date of a given key, and so on. An IBE system cannot help but be a one-size-fits-all system for these parameters. This may not be bad, it may actually be a simplifying assumption. However, expressing these concepts are part of why we have certificates despite the problems in managing them. There are two possible approaches to dealing with this paradox — one being to make an IBE system that codes a more formal certificate and then uses that as an IBE key, such as Gentry’s CBE, or this approach which adapts IBE so that it can be used within a traditional certificate system. 10 4th Annual PKI R&D Workshop Pre-Proceedings 9.3 Is it Possible to Prove Ownership of a String? When we describe how IBE works, we get to the Key Extraction phase and glibly say Alice authenticates herself to the PKG to get her private key. How? If Alice is already an authenticated user of the PKG, this isn’t very difficult. If it is to hotmail.com that Alice must prove ownership of alice@hotmail.com, this is an easy problem. If worst comes to worst, she has a password she can type in. If it is to brand-new-service.com that Alice must prove ownership of alice@hotmail.com, it is a bit more difficult, but hardly impossible. A simple, if low-security mechanism is for brand-new-service.com to send her an email with some authentication token that she delivers back to brand-new-service.com. For those who believe this insufficiently secure, there are other protocols that are easy to devise that are more secure. For example, Alice could generate an ephemeral RSA key pair, give brand-new-service.com the public key, and then deliver to brand-new-service.com the decrypted authentication token as before. While not perfect, it’s an improvement. Devising a protocol that is immune to man-in-the-middle attacks is left as an exercise to the reader. However, if Alice must prove the ownership of "Alice Jones", then we have a very difficult problem. Names are hard to express in a certificate system, and among the many criticisms of certificate systems the most basic objections concern the way they handle naming [ELLISON00]. If a name is a key, then a certificate is a key, and all the naming problems we have in certificates we have in names. Making names be keys exacerbates this problem. If the IBE system uses other bit strings such as photographs, music, etc. as keys, proof of ownership could be arbitrarily hard, both technically and legally. 9.4 Performance Bottlenecks IBE systems in general suffer from centralization on many fronts. Not only does centralization create security issues, but it also creates performance issues. The PKG may have to do large amounts of work, especially when the system uses many short-lived keys. In this system, the need for the PKG to generate keys makes more work for it. Furthermore, generating a key for some cryptosystems such as RSA require more computation than for others, such as DSA. One possible solution to this problem is HIBE. HIBE expresses the user’s identity as a composite of identities. For example, Alice’s identity would be the tuple (IDAlice , IDhotmail.com ) [GS02] [HL02]. While attractive from a performance viewpoint, it also blurs the conceptual simplicity of a name being a key. It also requires that the identities themselves have some structure in them that can form a hierarchy. HIBE also provides a partial solution to the escrow problem as no single server has the key for any hierarchical identity; an adversary must compromise more than one part of the hierarchy. Additionally, systems that secret-split in a set of authorities could potentially also use this as a way to distribute the computational workload of IBE over the set. Nonetheless, performance is another consideration that IBE systems must take into account, and this one more than most, since there is no off-line generation of keys. 108 11 10 Conclusion This presents hybrid system that combines Identity-Based features with a conventional public-key cryptosystem. Its advantages over the previous systems are that it provides interoperability with existing systems and by becoming an on-line system avoids the security problems associated with other IBE systems that permit off-line key generation. Consequently, this brings the advantages of an IBE system — that any bit string be equivalent to a public key, without the disadvantages of permitting an attacker complete knowledge of the PKG. It thus brings at this modest cost the advantages of IBE to conventional public key cryptosystems. 109 12 4th Annual PKI R&D Workshop Pre-Proceedings References [AY03] S. Al-Riyami and K. G. Paterson, Certificateless Public Key Cryptography, extended abstract in Proceedings of ASIACRYPT ’03, LNCS 2894, Springer-Verlag, 2003. Full paper available in the IARC eprint archives, . [BB04] D. Boneh and X. Boyen, Secure Identity Based Encryption Without Random Oracles, extended abstract in Proceedings of CRYPTO ’04, LNCS 3152, Springer-Verlag, 2004. Full paper available in the IACR eprint archives, . [BF01] D. Boneh and M. Franklin, Identity-Based Encryption from the Weil Pairing, Proceedings of CRYPTO ’01, LNCS 2139, pages 213-229, Springer-Verlag, 2001. [BIHAMCHEN04] E. Biham and R. Chen, Near-Collisions of SHA-0, Proceedings of CRYPTO ’04, LNCS 3152, Springer-Verlag, 2004. Also available in the IACR eprint archives, . [COCKS01] C. Cocks, An Identity Based Encryption Scheme Based on Quadratic Residues, Proceedings of the 8th IMA International Conference on Cryptography and Coding, LNCS 2260, pages 360-363, Springer-Verlag, 2001. [ELLISON00] C. Ellison, Naming and Certificates, Proceedings of the tenth conference on Computers, freedom and privacy: challenging the assumptions, ACM, . [GENTRY03] C. Gentry, Certificate-Based Encryption and the Certificate Revocation Problem, Proceedings of EUROCRYPT ’03, LNCS 2656, pages 272-293, Springer-Verlag 2003. Corrected version available as . [GS02] C. Gentry and A. Silverberg, Hierarchical ID-Based Cryptography, Proceedings of ASIACRYPT ’02, LNCS 2501, pages 548-566, Springer-Verlag 2002. Also available as . [HL02] J. Horwitz and B. Lynn, Toward Hierarchical Identity-Based Encryption, Proceedings of EUROCRYPT ’02, LNCS 2332, pages 466-481, Springer-Verlag 2002. [JOUX04] A. Joux, Multicollisions in Iterated Hash Functions, Proceedings of CRYPTO ’04, LNCS 3152, Springer-Verlag, 2004. [LQ03] B. Libert and J. Quisquater, New Identity Based Signcryption Schemes from Pairings, IEEE Information Theory Workshop, 2003. Also available as . 110 13 4th Annual PKI R&D Workshop Pre-Proceedings [LQ04] B. Libert and J. Quisquater, What Is Possible with Identity Based Cryptography for PKIs and What Still Must Be Improved, Proceedings of EUROPKI 2004, pages 57-70, Springer-Verlag 2004. [MILLER56] G. A. Miller, The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, The Psychological Review, 1956, vol. 63, pp. 81-97. Also available as . [SHAMIR79] A. Shamir, How to share a secret, Communications of the ACM, Volume 22, Issue 11 (November 1979), pages 612-613. [SHAMIR84] A. Shamir, Identity-based Cryptosystems and Signature Schemes, Proceedings of CRYPTO ’84, LNCS 196, pages 47-53, Springer-Verlag, 1984. [TLS] T. Dierks and C. Allen, The TLS Protocol Version 1.0, RFC2246 [WANG04] Xiaoyun Wang and Dengguo Feng and Xuejia Lai and Hongbo Yu, Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD, IACR eprint archive, . [ZHENG97] Y. Zheng, Digital Signcryption or to achieve cost(signature & encryption) « cost(signature)+cost(encryption), Proceedings of CRYPTO ’97, LNCS 1294, pages 165-179, Springer-Verlag, 1997. 111 14 4th Annual PKI R&D Workshop Pre-Proceedings A PROXY-BASED APPROACH TO TAKE CRYPTOGRAPHY OUT OF THE BROWSERS FOR BETTER SECURITY AND USABILITY Marco Antônio Carnut (kiko@tempest.com.br) Evandro Curvelo Hora (evandro@tempest.com.br) Tempest Security Technologies Universidade Federal de Sergipe - DCCE/CCET ABSTRACT This paper describes the implementation of a multiplatform selective filtering/rewriting HTTP proxy that allows the PKI-related operations – such as digital certificate issuance, web form field signing and HTTPS client authentication – to be performed entirely outside the browser, even though the browser continues to be used for what it’s good at: rendering web pages. Implications such as better usability through improved user interfaces are discussed in light of a prototype implementation. 1 INTRODUCTION this feature. In IE, it can be implemented using The SSL/TLS protocols were originally designed to ActiveX or even Java (although that requires installing provide encrypted and authenticated channels for web CAPICOM, making the process less transparent), but servers and clients. Even today, they are almost they tend to be too cumbersome for large-scale exclusively used to authenticate servers, despite its deployment. support for client authentication. There are many This paper investigates an alternative way to provide reasons for that: in [4], it is shown that getting a client client certificate-based authentication and web form certificate – even a free an instantaneous one – is too signature, along necessary subsidiary services such as much of a hassle for the average user. Internet digital certificate issuance, by performing all the Explorer (IE), the most popular web browser, makes it cryptographic and user interface chores in a separate all too easy to store the certificate without a program: we use a selective cryptographic passphrase; besides, its client certificate-based logon filtering/rewriting HTTP proxy to implement all the window is confusing, showing expired and revoked PKI-related features, leaving to the browser only what certificates along with valid ones and it is outfitted it’s good at: rendering web pages. This approach has with a “remember password” checkbox that causes the the advantage that it works with any browser that passphrase to be stored unencrypted, invalidating supports proxies. much of the security the process might provide. Specifically, we wanted to make a general purpose The way failures are handled is also confusing: when utility for handling digital certificates that provided the server can’t validate the client certificate (either easy-to-use digital signature generation and because it couldn’t build a trusted certificate chain or verification functions; and that could be integrated the client certificate was found to be revoked), it with the web browser to allow web form signature and simply breaks the connection; there are no provisions client certificate authentication in HTTPS with a much to redirect the user to a nice page explaining what went better user interface and security features under our wrong and how to fix it. control. We also wanted this utility to be a testbed for All these usability problems cause enough user new HCI ideas applied to client-side (primarily, but rejection that webmasters find it simpler to use weaker not limited to, web-based) PKI applications. authentication schemes such as This paper focuses on the cryptographic, PKI and name+password+cookies. Although vulnerabilities protocol issues needed to “take crypto on our own have been discovered (and in some cases fixed) in hands” (as opposed to letting the browsers do it), while most browser’s crypto implementations, bad human- simultaneously striving to maintain backwards computer interface (HCI) is often appointed as a compatibility. Although we do make extensive use of serious hinderance to PKI adoption in general [14] and screenshots to illustrate some features and preliminary client-based authentication in particular [18]. user interface (UI) ideas we implemented – and There have been a few attempts to improve the user- sometimes we even indulge in describing some of its friendliness of client authentication, such as VeriSign’s details and user feedback we received –, an analysis of Personal Trust Agent [17] and RSADSI’s Keon the merits of our tool’s UI is beyond the scope of this WebPassport [16]. However, as they are both ActiveX paper, for it requires entirely different approaches and controls, they are Windows-only solutions and since techniques. What we want here is to show one possible they are activated after the SSL handshake, they have way it can be done. to resort to proprietary authentication schemes. Besides general familiarity with the Another great promise brought by public key X.509/PKIX/PKCS standards and PKIs in general, this cryptography is the use of digital signatures as a way text assumes the reader has considerable familiarity to detect tampering on digital documents. Some web with the HTTP [1] and HTTPS [2, 3] protocols. browsers can natively sign the contents of web form fields, but many – most notably IE – do not support 112 4th Annual PKI R&D Workshop Pre-Proceedings HTTP HTTP proxy at Requests 3128/tcp Filter #1 Infrastructure Filters (version tag, chunked Filter #2 encoding, etc...) . . The Engager tells the HTTPS Engager . . dispatcher to use the same HTTPS . . proxy the browser is using Encryption HTTPS The engager changes the currently running Domain Filters Dispatcher browser instances’ Internet configuration to use Security features ourselves as proxy.. Web Form filters (web logon Signing Filter over HTTPS, form signing, etc) HTTPS-Capable The Engager configures the . . Server . . HTTP dispatcher . . to use the proxy server the browser was Filter #n previously using. HTTP Dispatcher Figure 1: Overall architecture of the client proxy, which runs in the same computer as the browser. The engager changes the browser’s proxy settings so that it uses our own local proxy. Before doing that, though, it detects which HTTP and HTTPS proxies the browser was using and configures our dispatchers to use them. This effectively puts us in the middle of the proxy chain. New HTTP requests originated by the browser will pass through our proxy, where our filters may act upon them. In fact, we have two filter chains, one for the outgoing requests and other for the incoming responses; some of them act upon the headers, other upon the bodies. Some features actually require several filters in cooperation to implement. If none of the filters actually consume the request (i.e., take it out of the chain), it reaches the default dispatcher in the end of the chain and it is sent as an HTTP request. The Encryption Domain filterset is a special set of filters that reroutes the requests that match certain criteria to be sent over as HTTPS. The HTTPS dispatcher makes use of the certificate store services (not shown in this picture) to validate the certificates and perform client authentication (with a friendly UI) if the site so requests. point to our own proxy described above, so that 2 OVERALL ARCHITECTURE we get to intercept all HTTP traffic initiated by Our tool, code-named Kapanga, is an executable the browsers. Engagers are described in detail in program that typically (although not necessarily) runs section 2.3 . in the same computer as the user’s web browser. A • Default Dispatcher: an embedded HTTP user schematic depiction of its overall architecture can be agent that sits at the end of the filter chain. It acts seen in Figure 1. A brief description of its major like a “default route” in a routing table: any components follows: requests that reach it are sent their destinations, • Certificate Store Manager (CSM): provides all either directly or via another next-hop proxy. It the underlying cryptographic services needed by also proxies any authorization requests (e.g., all the other components. It manages and provides Basic, Digest or NTLM authentication) that the access to all the cryptographic objects next-hop proxy may require, so the authentication (certificates, certificate revocation lists, private protocol is handled by the browser itself and any keys, signatures, etc) stored in various kinds of username+password dialog boxes that may be storage media (the local disk, removable storage required is also shown by the browser itself. Upon devices, crypto-capable devices such as smart receiving the results, it pipes them back to the cards, etc); provides access to cryptographic response filters, which also play crucial security algorithms and protocols. The CSM is detailed in roles. section 2.1 . • HTTPS dispatcher and the Encryption • Filtering HTTP Proxy Server: receives the Domain: similar to the default dispatcher, but requests from the browser and feeds them through tunneling the requests over TLS/SSL [2]. For the filter chain. If no filters consume the request, it performance reasons, it features support for is passed to the HTTP dispatcher nearly rehandshakes and session caching [3]. It relies unchanged. Filters may alter either the request heavily on CSM services for validating the before they’re sent to the dispatcher or the replies servers’ certificates and providing client berfore they’re sent back to the browser. These authentication if the server so requires. A request changes implement the program’s main features, is sent through this dispatcher if the host:port as it will be detailed further along. of the request is listed in a set called Encryption • Engagers: they are in charge of changing the Domain (this detour is actually accomplished by a HTTP proxy settings of all supported browsers to special filterset collectively known as the 113 4th Annual PKI R&D Workshop Pre-Proceedings “Encryption Domain filters”). As with the default certificate made by the private key of a user to dispatcher, it may either send the request directly indicate that it trusts that certificate (typically a or use the CONNECT method to tunnel it over a root CA). This signature is detached – that is, it is next-hop proxy [5] if the engager has previously stored in a separate file in a file format of our told it so. It is also responsible for sending back own devising; we will have more to say about any authentication requests that the next-hop attestations in section 2.1.1. . proxy may require. • Chaining: after the certificates are loaded from 2.1 Certificate Store Manager the physical stores, the CSM tries to chain them. First, duplicates are discarded and certificates Underlying the whole program is the Certificate Store issued by the same CA are sorted by their Manager, providing crypto and PKI services to the notBefore fields and assembled as a doubly- other subsystems: linked list. The best current certificate is selected • Certificate, CRL and private key enumeration by applying two criteria: a) it is the one with the and caching: all those objects can live in one or most recent notBefore and b) it must be still more physical media. The local hard disk is called within validity (that is, with the current date/time the primary store location, bringing a minimal set before its notAfter field). If no certificate of certificates right from the installation satisfies both requirements, we settle for the one procedure. that satisfies only (a). The user may configure one or more secondary After that we build several indices for fast lookup: locations. Those are usually removable media, one keyed by the certificate’s SHA1 hash, other such as CD-ROMs, diskettes or USB flash by its Subject Key Identifier extension [7] and memory devices (“pen drives”). Every three another by subject DN. This last one has a seconds or so the certificate store manager checks peculiarity: only the best current certificates make to see if these devices are readable and, if so, to this index; the future and previous editions rescans them. This way, a user may have and use don’t get there. his/her certificates/keys in a removable storage medium during their entire lifetime1. We then chain the certificates in the usual way, using the recently computed indexes to speed up Crypto devices such as smartcards are also finding the issuer of each certificate in the store supported, although they are handled as special (matching SKI/AKI pairs, when available, and by cases because some objects (private keys, subject/issuer DNs as a last resort). We set the primarily) may not be exported and we may only parent pointer of each certificate to the issuer and operate on them via the device’s built-in record its the depth in the tree (the whole chaining cryptographic capabilities. algorithm uses a breadth-first search precisely to The resulting in-memory cache can be seen as a make that trivial). concatenation of all the contents of all of the CRLs are considered as an appendage to their devices. CRLs are handled as a special case – issuer certificates and are chained to them. Private since some of them tend to get very big, they are keys are also appendages and are linked to the deallocated from memory as soon as the CSM is certificates with the corresponding public key (the done using them in the trust calculations. private key format stores the public key as well, so Private keys are handled as special cases as well. this comparison is straightforward). When stored in crypto devices, the CSM directs • Trust Status Calculations: With all the all its crypto primitives to the device’s drivers to certificates and associated objects properly make use of its embedded functionality; chained, we start to verify their validitity periods, otherwise, they are loaded only when needed and signatures of its issuers, attestations, etc. It is the crypto primitives (signing/decryption) are interesting to notice that all trust calculations are directed to the software-based implementation. relative to the currently selected default ID, since Our certificate store has another type of object attestations depend on it. Thus, whenever the user called attestation signature or simply attestation. changes the default ID via the GUI, the whole It is a signature block on someone else’s trust statuses are recomputed. Section 2.1.2. describes each trust status in detail. The CSM has a few other utilities and services: 1 Some of our users like to call this “the poor man’s smartcard”. We • Public CSM Server: We coded a version of the try to tell them this is a particularly nasty misnomer – not only because certain media such as USB “pen drives” are actually more CSM in a web server that is offered as an expensive than smartcards (even including the cost of the reader), associated on-line service to the user and acts a but also because they lack the tamper-proofness and crypto public certificate/CRL repository. Over the years, capabilities of the latter. 114 4th Annual PKI R&D Workshop Pre-Proceedings n o q s r p t Figure 2: The CSM trust calculation results as displayed in the GUI. Here we have a certificate store with (1) three unattested roots and (2) three attested, trusted roots. There is also an Intermediate CA (3) that cannot be trusted because it’s unchained, meaning that we lack its issuer root. All children of trustred roots are marked as indirectly trusted unless they’ve been revoked (4), their signatures don’t match (6), or it’s not within its validity period (7). The item marked in (5) is the current ID (aking to PGP’s “default key”). All trust calculations are relative to the attestations (detached signatures on root CAs) this ID has previously performed. we’ve been dumping on this server every CA removing from the user the possibility of doing things certificate we lay our hands on. Whenever a manually if he/she so wishes. certificate is unchained, the Kapanga may query the CSM server (either automatically due a 2.1.1. Attestations configuration option or manually through a pop- Attestations are signatures of a private key in someone up menu in the GUI) to see if it knows the missing else’s certificates as a means of informing Kapanga issuer. The external CSM may also return CRLs – that the owner of that private key trusts the signed it has a built in robot that tries to fetch CRLs of all certificate. They are akin to PGP’s key signatures or CAs it knows about from its distribution points. introductions, except that they are stored in a file • Automatic CRL Download: Just like the public separate from the certificate itself. online CSM server, the program’s internal CSM We originally implemented attestations only for Root has a similar feature – it automatically tries to CAs as a more secure means to tell the CSM that download the latest CRLs from the addresses particular CA is to be considered trusted. We were advertised in each CA certificate’s trying to avoid a simple vulnerability most browsers cRLDistributionPoints extension. It can have: it’s quite easy write a malicious executable that do so upon user request or automatically in the inserts a new fake root CA in their trusted certstore – background. In the automatic mode, the list of in IE’s case, it can be done in a few lines of code, since candidates URLs is rebuilt each four hours the root CAs are stored in the registry; for Mozilla- (configurable) and we try to downloads CRLs derived browser’s, it requires only slightly more effort, from them. In case of success, the whole trust since the root CAs are in a Berkeley-DB file. settings are recomputed and redisplayed. If some As we will see in the next section, Kapanga trusts root download fails, the next attempt time is subject to CAs only if they’re signed by the user’s key. We say an exponential backoff algorithm with a maximum that the only truly trusted certificate is the user’s own, period of one week. because he/she has the corresponding private key. All The overall effect we tried to achive is that the user the trust placed in the other certificates, even root doesn’t have to worry about the intricacies of certificates, stems from the user. Hopefully it also certificate management at all: he/she would only use makes the root insertion attack slightly harder, for it the program features, collecting certificates along the will require the attacker to induce the user to sign the way, and the CSM will do its best to ascertain its trust corresponding certificates. statuses and keep everything updated – without 115 4th Annual PKI R&D Workshop Pre-Proceedings Figure 3: Manual Attestation Process. The user must sign the Root CA’s certificate with his/her private key. Only then this CA will be considered directly trusted. The UI was designed as a single- step dialog box presenting the most important certificate identifiers for manual checking against other trusted sources, instead of the unecessarily complex and sometimes scary multi-step wizards most browsers have. The text succintly explains that this must be an informed decision. In this screenshot, we see the program requesting the private key’s passphrase, which reinforces the sense of importance of this action. An always- enabled but impossible to disable check box reminds the user that passphrases are case- sensitive. Root CA attestations are also integrated with the certificate issuance/import dialogs, so users rarely come to this dialog to perform root attestations; it is more often used to attest certificates other than roots. While this does improve security, this may seem as an this status overrides the “Unchained” and “No extra complication: we require the user to have a path to trusted root” statuses described below. certificate and private key; Kapanga is nearly useless if • Directly Trusted: this means that this certificate the user doesn’t, since it will trust no one. After getting has been attested by the current user. In other a certificate, the user would need to perform a few words, there is a signature block on this certificate attestations. We tried to make this simple by correctly verified against the current user’s public integrating the attestation process with the certificate key as proof that the user gave his/her direct issuance/import processes: as shown in Figure 4, when consent that this certificate must be considered the user gets a new certificate, a few checkboxes cause trusted. If this a CA certificate, this causes all its root to be automatically attested, as well as all other child certificates to be considered indirectly roots this root trusts: root attestations on other roots are trusted. our bridge-CA mechanism. • Indirectly trusted: this means that the CSM has Later on, we generalized the attestation system: the verified that the signature of the issuer is valid and user now can sign any certificate he/she chooses. that the issuer is trusted (either directly or This effectively makes Kapanga’s trust system a cross- indirectly). breed between the X.509’s strictly hierarchical and • Not Within Validity: the certificate is not trusted PGP’s web-of-trust models. While we were inspired because the current date and time is after the value by and tried to follow RFC 3280’s certificate specified in the certificate’s notAfter field or validation rules, we can’t really say we follow them to before the value specified in the notBefore the letter because it ended up evolving in a different field. This status overrides all others (even the direction. Ultimately Trusted stauts): the CSM doesn’t even Other interesting analogies can be drawn with other bother checking anything else. public-key based systems: for instance, signing an • Unchained: the certificate cannot be considered unchained server certificate in Kapanga is akin to as trusted because it we don’t have its issuer. This adding a SSH server key to the status applies only to intermediate CAs and end- ~/.ssh/known_hosts file, except it’s harder to entities; it obviously can’t happen in Root CAs. spoof because of the signature. This status can override all the previous ones except the “Ultimately Trusted”. 2.1.2. Trust Statuses • Not Attested: this only happens to Root CAs. The The trust calculations assign one of the following certificate cannot be considered as trusted because statues for each certificate: we either have no valid attestation signature on • Ultimately Trusted: this means that we have the this root from the current user’s. private key corresponding to this certificate. Thus, • No path to trusted root: the certificate cannot be it is an identity we can assume. Those certificates considered as trusted either because the root of the are considered to be “the root above the Roots”, chain has not been attested (it is not directly the true starting point all trust stems from. As a trusted) or some of its issuers are unchained (the result, such certificates are considered trusted chain doesn’t go all the way up to a root CA). even if they’re not properly chained or if its chain doesn’t go all the way up to a trusted root; we say 116 4th Annual PKI R&D Workshop Pre-Proceedings • Revoked: the certificate is not trusted because its certificate. The rest of this subsection describes serial number is listed in its CA’s Certificate some particularities of this process. Revocation List (CRL) and the CRL itself is valid. In the first step, the user enters his name and email The trust statuses for CRLs work a bit differently. A address, being also warned that the process requires CRL is considered valid if the signature of its CA being online or else the process will fail – this is unlike matches just fine, regardless of whether it is outdated PGP. The user is also asked to reconfigure his/her or not. If a given certificate is listed in some CRL, it is spam filters to prevent the CA notification messages flagged as revoked even if the CRL is not the freshest from being blocked. possible; the CRL checking engine tries to do the best After that, the wizard asks the CA whether the email with what it has. It is the responsibility of the address the user requested is already taken – that is, automatic CRL dowload feature to try to keep CRLs as whether the CA has in its database a valid certificate up-to-date as possible. issued for that email address. This is implemented by When the CRL checking engine is asked about sending the CA a request for a “Revocation whether a certificate is revoked or not, it returns an Reminder”. If the server responds with a “No valid answer consisting of three items: certificate associated with this email address” message, • Is_revoked: a tristate flag saying whether the we let the user proceed. Otherwise we inform that the certificate is revoked (true), or not (false) or if we user is going to receive an email with revocation can’t ascertain because we have no CRL for this instructions and ask him/her to follow it before coming CA (unknown). If this flag is unknown, the back to try to issue the certificate again. In this remaining two items describe below are situation, the “Next” button of the wizard is grayed undefined. out, making impossible to proceed. The next step is setting up the passphrase – historically • Is_outdated: it says whether the CRL used to the step users hate the most. This is constitutes a good compute the is_revoked status is outdated or not. opportunity to describe what kind of usability ideas • Reference date: if is_revoked is true, it returns we’ve been experimenting with, so we will detour the revocation time and date as taken from the from the “protocol nuts and bolts” approach we’ve CRL. Otherwise, it returns the CRL’s been adopting so far and make an aside about our UI lastUpdate field, meaning that we can be designs. certain that this certificate isn’t revoked only up to The philosophy is to try to steer the user to do the right the moment the CRL was issued. thing, both through education and trying to prevent unwittingly dangerous actions. However, it can’t be 2.1.3. Certificate Issuance, Import and Export frustrating either, so the restrictions must not be Another important service provided by the CSM is absolute; they have to be bypassable, although the user providing support for having new certificates issued must feel frowned upon when choosing the insecure through a Certificate Authority. From the point of view path. of the CSM itself, its just a matter of having an RSA As usual, we have two passphrase text entry boxes. By keypair generated and converting it to an Netscape defaut, they are set not to show the text being typed, SPKAC (Signed Public Key and Challenge, see [12]) replacing the characters by asterisks. Just like in PGP, format (a Certificate Signing Request would seem a however this is bypassable by unchecking a “Hide better choice, but the reason for that will become clear Typing” checkbox. This is needed because some poor further along). typist users take too many attempts to make the From the point of view of the user interface, there are content of the text boxes match that they become two very different implementations: frustrated and quit. But unlike in PGP, if they opt to do • The classic web-based style, in which the user this, they get a insistent blinking message warning directs his/her browser to the CA web page, fills them to make sure they aren’t being watched or some web forms and the browser activates the key filmed. generation procedure. Since this issuance system We also implemented a warning about Caps Lock is intrisically intertwined with the filter system, it being enabled, now common in many programs. will be described along with our discussion of the Also common is the passphrase quality meter. The HTTP filters in section 2.2 . metering algorithm tries to estimate the entropy in the • We also wanted to have a PGP-like wizard-based password roughly by making a weighted average of instantaneous key generation. To that end, we two criteria: the word entropy and the character implemented a specialized wizard that uses entropy. The former is exceedingly simple-minded: we FreeICP.ORG’s Entry-Level CA [4] to allow the assume that each word adds about 11 bits of entropy. user to get a free, instantaneous short-lived The latter is more complicated: we determine the bounding set of the characters of the passphrase in the 117 4th Annual PKI R&D Workshop Pre-Proceedings ASCII code space and use it as an entropy per diceware passphrases are more secure than those character estimator. Then we multiply it by the number approaches seems to convince them. On the good side, of characters and divide it by the efficiency of a however, our rejection rate has been zero precisely customized run-length encoder. This has the effect of because we give the users the choice: they can simply yielding very low scores to regular sequences such as disable the quality meter and ignore the suggestion box “aaaa” and “12345”. The quality meter displays its altogether if they really want to. Over time, we see that score in a progress bar and with a scale categorizing users gradually start to explore the passphrase them as “simple”, “good” and “complex”. suggestion box and the number of good passphrases The reason we didn’t bother to be much more slowly increases. A quantitative characterization of scientific than that with the quality meter is that in our those intuitive perceptions may make fertile ground for early attempts it became clear it would result in it a future paper. being overly frustrating to the end users. Our priority The last page of the wizard is the one where the key is to keep the users happy (or at least not too unhappy), pair is generated. As many other implementations do, a so we calibrated (or rather downgraded) the algorithm progress bar tracks the possibly lengthy key generation many times to quell their complaints. We did perform process; we were working on an educational animation some research about it, but in the limited time we had to add to this window, but a discussion of its features we could find no real good papers with general design is beyond of the scope of this paper. guidelines for passphrase quality meters. We opted for After the key pair is generated, the private key is trial and error based on the users’ feedback. encrypted with the passphrase and saved in the In the end, we struck a middle ground with the Certificate Store. The public key is converted to the following strategy: we made the meter slightly SPKAC format. When the wizard is invoked from the challenging and by default it doesn’t allow you to go Keygen Interceptor filter (see section 2.2.2. ), we on if the score doesn’t lie in the “good” range. return this SPKAC to the filter. We also store along However, we added a checkbox that allows you to with the private key the state of the attestation disable the meter restriction altogether – in which case checkboxes in the final page of the wizard (the CSM the user gets a polite message telling something like has facilities to add property=value tags along “now you’re on your own risk, hope you know what with any object) – they will be needed later when it’s you’re doing – don’t say I didn’t warn you”. time to pick up the issued certificate and insert it in the A frequent question our users pose is “what’s a good CSM. passphrase anyway?” To try to answer that we If, on the other hand, wizard has been invoked from implemented the passphrase suggestion dialog shown the main menu, the SKPAC is sent in a HTTPS in Figure 4d. It generates passphrases suggestions message to the FreeICP.ORG Entry-Level CA (the using the Diceware method [18], which consists of destination URL is configurable but with a hardcoded generating a random number and mapping them onto a default). The Entry-Level CA responds immediately dictionary of 7776 words and common abbreviations, with the certificate in a PKCS#7 bag right in the HTTP yielding 12.92 bits of entropy per word. (The method response body. was originally designed to be performed by hand, pencil and paper using five dice tosses to select each 2.2 Filters word.) With 5 words we get more than 64 bits of Filters are routines that change the request header, the entropy, which provides good enough protection request body, the response header or the response body against brute force attacks under quite general of the HTTP requests received by our internal HTTP conditions while remaning reasonably easy to server. In our implementation, each filter can change memorize. only one of these items; the cooperation of several Our user’s feedback to the passphrase suggestion box filters is often needed to implement a single particular has been a mixed bag. Some love it and many hate it – feature. The filters are organized in two filter chains: the primary complaint is that passphrases are way the request chain and the response chain. Within a long. Many system administrators have been asking us chain, the filters are executed sequentially in the order to add a passphrase suggestion algorithm that matches they’ve been set up. Some filters depend on others, so their password policies like “8 characters with at least the chain setup tries to ensure that they are one punctuation character and a number not in the end topologically sorted. nor the beginning”. No amount of arguing that the 118 4th Annual PKI R&D Workshop Pre-Proceedings (a) (b) (c) (d) (e) (f) Figure 4: Wizard-style UI for using the FreeICP.ORG instantaneous Entry-Level certificate issuance process. In (a) the user enters his/her name and email address, while being advised the need to be online and that notifications will be sent over email. In (b) the CA is queried to see whether that email address is already in use. If so, the CA will send an email with revocation instructions and the process is halted. In (c) the user sets up a passphrase for the private key that is about to be generated. A quality meter gives prevents the user from choosing too weak a passphrase – unless the “Enforce quality restrictions” checkbox is disabled. The status texts indicate in real time when the confirmation matches and some educational security tips are also offered. In (d) we see the passphrase suggestions dialog: ten suggestions are put forth so that the user can choose visually without revealing the passphrase to shoulder surfers. As the first character is typed, all fields turn to asterisks. Each time the user correctly retypes the passphrase causes the chosen box to blink. Typing a different one resets the counter. Cheating by using copy-and-paste works but the user is politely warned that this doesn’t help memorization. In (e), the key pair has been generated, converted to SPKAC, sent to the CA and the signed certificate has been received back. In (f) we see the new certificate and its associated private key in the certstore main window, already set as the default ID. The “Mark the Root CA as Trusted” checkbox caused the attestation of root certificate, so it’s shown as directly trusted; the “Mark all cross-certified Root CAs as Trusted” checkbox caused an attestation on VeriSign’s Root CA as well. The whole process takes 20 seconds or so for experienced users and less than two minutes for novices – most of it spent figuring out how to either please or bypass the quality meter. The user gets out of the process with all attestations already performed, so he/she will rarely have to perform manual attestations. Notice that request filters can consume the HTTP default dispatcher at the end of the chain. It then request entirely, removing it from the chain so that it becomes this filter’s responsibility to either issue the won’t reach neither the subsequent filters nor the 119 4th Annual PKI R&D Workshop Pre-Proceedings request and insert the response back in the chain or to browser’s identity and version. This will be abort the request entirely. needed to redirect us to the Nestcape-style Filters can be divided in two main groups described in certificate issuance system in commercial web- the following subsections. based CAs. Second, it arms the Keygen interceptor filter. 2.2.1. Infrastructure Filters • Version Tag: A simple request header filter that Infrastructure filters aren’t directly involved in appends an identifier and our version numer to the implementing the security features; they primarily User-Agent header, without removing the provide services for the other filters. A description of browser’s identification. This allows the web the most important filters in this category follows, server to detect whether our tool is enabled and roughly in order from the simplest to the most perhaps offer customized functionality. For complex: instance, a client authentication-capable website could detect that Kapanga is engaged to the • Command Parser: this is a simple request header browser and offer its login URL already including filter that detects and extracts a special query the x-kapanga-cmd=addsite command. string on the form “x-kapanga- cmd=[command]” from the URL. Below we This filter is also responsible for “lying” about the have a short summary of the commands; each will browser’s identity when the command parser has be discussed in detail further along: previously received the x-kapanga- cmd=ua(string) command. It changes all http://example.com/?x-kapanga- User-Agent request headers to the specified string cmd=addsite(port,title,errpath) (typlically something like “Mozilla/5.0”). It also Adds the current site (example.com:80) to the replaces all occurences of encryption domain. TLS/SSL connections will be navigator.appVersion in JavaScripts by sent to the TCP port specified in “port”. If the certificate validation fails, the request is redirected the specified string, since most web-based to “errpath”. The parameter “title” is a user- commercial CA software uses embedded scripts to friendly added to the bookmark/favorites lists. determine the browser’s version. http://test.com:8080/?x-kapanga- • Encoding Dampers: quells any encoding cmd=delsite negotiation we can’t understand, such as gzip or deflate encodings. In our current implementation, Removes the current site (test.com:8080) from the we don’t support any encodings, so this is a encryption domain. simple filter that sets the the Accept- http://yasite.com/?x-kapanga- Encoding field of the HTTP request headers for cmd=sign(data,sig) the identity transformation. This is needed Prepares to sign the field named “data” in an web because several filters down the chain will need to form that will be downloaded as a result of this parse the HTML when it comes back. This, of request. The signature will be performed when the course, hinders any performance gains that those user hits the submit button in his/her web browser encodings might bring. Future implementations and the result will be placed in a (possible new) will replace the damper by a proper set of form field named “sig” as a S/MIME signature. decoders. http://somewhere.net/?x-kapanga- • Chunked Transfer Encoder: converts the HTTP cmd=send-usable-ids response bodies to the chunked transfer encoded Forces the request to become a POST and sends a form (see [1], section 3.6). This is needed because list of valid ultimately trusted certificates (without the response body filters will very likely change their respective private keys, of course). the length of the body, so the browser must not http://whatever.org.ar/?x- employ the ordinary strategy of relying on the kapanga-cmd=activate(sha1) Content-Length header. All that, in turn, is a Sets the ultimately trusted certificate with consequence of the fact that the body filters fingerprint SHA1 as the default for client perform on-the-fly rewriting, that is, they act upon authentication with the server specified in the each data block read from the network. The URL (in the example, “whatever.org.ar:80”) alternative would be to buffer the whole body, http://dummy.net/?x-kapanga- compute its new length after all filters had been cmd=ua(string) applied and then send it along to the browser – a bad idea because response bodies can grow This command interacts with two filters. First, it arbitrarily large, often several megabytes long, tells the Version Tag filter to change the User- which would make latency too high and memory Agent header to string, effectively lying about the consumption prohibitive. The Chunked Transfer 120 4th Annual PKI R&D Workshop Pre-Proceedings Encoding scheme was invented precisely for this kind of situation when we don’t know beforehand the size of the HTTP object we’re transmitting. The chunked encoder converts this to: HTTP/1.1 200 OK An example may clarify what those filters accomplish. content-type: text/html Suppose our browser issues the following HTTP transfer-encoding: chunked request (indented for better readability): GET http://testserver.example.com/t1.html?x- 40 kapanga-cmd=delsite HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, Infrastructure filters demo application/vnd.ms-powerpoint, </TIT application/msword, 40 application/x-shockwave-flash, */* LE> Accept-Language: pt-br </HEAD> User-Agent: Mozilla/4.0 (compatible; MSIE <BODY> 6.0; Windows NT 5.1) <H1>Test!</H1> Host: testserver.example.com All's well. Connection: Keep-Alive </BODY> </ The full URL on the GET request gives away the fact 5 that our browser was configured to use a proxy. This HTML> request also includes a Kapanga-specific command. 0 After passing through the infrastructure filters, it would be sent over the network like this: In this example, we lowered the maximum chunk size GET /t1.html HTTP/1.1 to 64 bytes to accentuate the encoding result; in our accept: image/gif, image/x-xbitmap, actual implementation, the maximum chunk size is image/jpeg, image/pjpeg, 32Kb and it almost never gets that big because the application/vnd.ms-excel, networking layer sends it to us in even smaller chunks application/vnd.ms-powerpoint, application/msword, due to the underlying TCP buffers. application/x-shockwave-flash, */* The chunk encoder filter has some heuristics to detect accept-language: pt-br accept-encoding: identity;q=1, *;q=0 old browsers (such as IE3) that don’t support the connection: keep-alive chunked transfer encoding. In those cases, it refrains host: testserver.example.com from altering the body but it also quells the HTTP proxy-connection: Keep-Alive keepalive feature, so that the browser will rely on the user-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) + Kapanga connection termination to know when the body data 0.22 finishes. Since in this example Kapanga was not configured to relay the request to another proxy (that is, IE was not 2.2.2. Feature Filters using a proxy before the engager did its job), the URL These are the filters that actually implement the in the GET line is relative. Also notice that the security-relevant features, relying in the infrastructure command parser removed the “x-kapanga-cmd”. provided by the previous filters and the CSM: The encoding damper has also left its mark in the • Web Form Signer: this is a request body filter Accept-Encoding line telling that only the identity that acts only on POST requests with the encoding is acceptable and all others are not. We can “application/x-www-form-urlencoded” MIME also see that the version tag filter added our name and type. It is activated when the command parser version number to the User-Agent line. previously received a command of the form After the request is issued over the network, the server sign(in,out,flags). The argument “in” is responds with something like this: the name of a form field in the current page form HTTP/1.0 200 OK which the filter will get data for signing. The filter Content-Type: text/html displays a dialog box confirming the data being Content-Length: 132 signed and requesting the passphrase for the private key that will be used for signing. When it <HMTL> receives these data from the user, it creates a <HEAD> <TITLE> S/MIME signed message and encodes as a Infrastructure filters demo (possibly new) form field named “out” (if “out” is ommited, it is assumed to be the same as “in”). The flags control things like whether we want our

Test!

own certificate included in the signature, whether All's well. 121 4th Annual PKI R&D Workshop Pre-Proceedings (b) (a) Web Form Signing Demo
Web For Signing Demo (c)
Figure 5: The web form signing filter in action. In (a) we see a minimalistic web in the browser and its source HTML. Notice the action URL with a Kapanga special command. The command parser field intercepts this command and set things up to intercept the POST request body and sign the “in” field, putting the result in a new form field named “out”. The final one in the sign command is a flag to hasve the S/MIME signer not include the signer’s certificate, just to keep the signature block small enough to fit this screenshot. In (b), the exact intercepted data that will be sign is shown in a dialog box, where the program allows the user to specify which key he/she wants to sign with and asks for the key’s passphrase. In (c), the signature has been performed and sent to the server. A script in there displays the signed block for us. For sake of brevity, we have shown only the successfull case. Lots of failure conditions are handled as well – for instance, when the signature doesn’t match, or the signed data has been changed by the client, when the user cancels without signing or when the proxy isn’t activated. to add the whole certificate chain up to the root, the request to become a POST (even if the etc. browser has sent it as a GET or HEAD). Kapanga The advantage of this approach is that we can add then builds a body with a list of PEM-encoded form signing functionality to some web ultimately trusted certificates it has. This is application just by activating Kapanga and making extremely useful because the site can know in just minor changes in the web application – if it advance which identities we can assume, inform doesn’t bother to verify the signature, it’s just a the user which ones are acceptable or not and help matter of chaning the HTML to include the sign the user select an appropriate one for login or command and storing the “out” field somewhere. registration, reducing the likelihood of frustrating A signature verification engine, however, would failures. be recommended to deal with exceptions such as The webmasters we have been working with point invalid signatures or to ensure that the signed this particular feature as the one that mostly contents is the same as previously sent (since it’s contributes for the overall user acceptance – it within the client’s control, a malicious user may makes it viable to make helpful web-based change it). certificate enrollment/registration system almost • Usable ID enumeration: This filter is triggered as simple as traditional name+password+cookie by the “send-usable-ids” command. First, it forces methods, as shown in Figure 7. 122 4th Annual PKI R&D Workshop Pre-Proceedings (a) (b) (c) Client Auth Demo (f)
Client Auth Demo

You are: O=$SSL_CLIENT_S_DN_O,..., CN=$SSL_CLIENT_S_DN_CN
Got your cert (chain is ok, didn't check (e) revocation though):

$SSL_CLIENT_CERT
(d) Figure 6: The HTTPS Logon filterset in a client authentication scenario. In (a) the user directs the web browser to an HTTP URL containing the command for adding the site to the Encryption Domain. As Kapanga was engaged to the browser, the request is actually sent over HTTPS because the command parser filter is executed early in the filter chain. Thus, when the request reaches the HTTPS Logon filter, the site address and port is already in the Encryption Domain. In (b), the site has requested client authentication and Kapanga asks the user which certificate he/she wants to use and the passphrase of its associated private key. Unlike Internet Explorer, Kapanga doesn’t show expired, revoked or altogether untrusted certificate, nor has a “remember password” checbox to ruin the whole security of the process. In (c), and the server have sucessfully completed the TLS handshake, sent the request and got the response back, where we see that the server sucessfully received and validated the user’s certificate. In (d) we see the returned page source HTML; comparing with the source HTML template in (f), we can see that the absolute URL in (e) was rewritten (notice the change from “https” to “http”) so that the image download would pass through our proxy as well. Granted, this kind of enumeration may be abused certificate or if it’s not ultimately trusted, no by rogue sites to collect email addresses or action is performed. tracking the user’s habits. We argue this is a This command is typically used in pre-logon page necessary evil to provide a seamless HTTP just before the “addsite” command to have the HTTPS transition. Just in case, we left a correct ID selected by default in the Web Site configuration option that allows the user to either Login Dialog (where the user is prompted for the disable this feature entirely or get a popup then the passphrase). site sends the enumeration command. • HTTPS Logon: this filter is activated by the • Remote ID activation: this filter is trigged by the “addsite” command previously seen by the “activate(sha1)” command. It sets the preferred Command Parser filter. Recall that this command default ID for this site (as identified by the host has three parameters: the SSL port (443 by portion of the URL) as the certificate with the default), a user-friendly site title/name and the specified SHA1 fingerprint. If we have no such error redirect URL. 123 4th Annual PKI R&D Workshop Pre-Proceedings Figure 7: The send-usable-ids command allows the web application to provide friendly account creation assistance, explaining beforehand which certificates are acceptable and which are not and thus minimizing frustrating failures. The “login” and “register” links, use the activate command to force that particular certificate to be selected, minimizing user errors and then redirects to another URL with the addsite command, inserting the site into the Encryption Domain and starting the transition to the HTTPS site. Even so, the SSL handshake might still fail if the site’s certificate doesn’t pass Kapanga’s validation. In this case (not shown in the picture) the “errpath” parameter in the addsite command would redirect the user back to a page explaining what went wrong and offering further help. At the bottom of the page, a form allows the user to start the wizard- based certificate issuance process directly from the web page: then clicking on Issue, the wizard pops up with the name and email fields already filled in. The first thing this filter does is a purely user- CSM deems the it untrusted or if any network or friendliness action: it inserts the site URL and title handshake error happened, the dispatcher displays in the Bookmarks/Favorites list (accessible via a a dialog box explaining the failure and returns menu), unless there is already a bookmark for this down the response chain a redirect to the error site there. That way, the user can easily come back URL specified in the site’s entry in the Encryption to this site without having to remember the URL. Domain (if none was specified, the connection is simply broken). This way, the site has an Then the filter inserts the site’s address in the opportunity to display a nice message telling the Encryption Domain, which is just a simple set user that the HTTP HTTPS transition failed mapping host:port pairs to SSL ports and error and maybe provide options to retry or choose URLs. Since the Encryption Domain filter is right other authentication options (such as plain old next in the chain, the request will be immediately name+password). This in direct contrast with rerouted to the HTTPS dispatcher. popular web browsers, which simply break the • Encryption Domain Filter: this filter checks connection on SSL failures, leaving the non- whether the host:port in the URL of the current technical user wondering what went wrong. request is in the Encryption Domain. If it isn’t, the Finally, if no errors occurred and the certificate is filter simply lets it follow its way on the filter held as trusted, the original HTTP request is sent chain, so it will ultimately reach the standard over the HTTP tunnel and the response inserted dispatcher and sent to the network over HTTP. back in the response filter chain. Also notice that, Otherwise, the request is taken out of the chain (so due to the SSL session caching, the whole it won’t reach the standard dispatcher anymore) verification process above happens only in the and fed to the HTTPS dispatcher, which, in its first connection to the site or when the cache entry turn, starts the SSL handshake to the port expires. specified in the site’s entry in the Encryption • URL Rewriter: This filterset is actually part of Domain. the HTTP Logon filterset described above. It acts If the server requests client authentication, the only on text/html MIME types on requests HTTPS dispatcher asks for the user’s private key through the HTTPS user agent. Its main purpose is for the default ID set for this site; if this key is not to rewrite URLs of the form: cached, the CSM will display a dialog box stating https://example.com/ the exact site name and prompting for the user’s private key. If, on the other hand, the server as doesn’t require client authentication, this step is http://example.com/ skipped. Supposing, of course, that “example.com” is in the At this point in the SSL handshake, the HTTPS encryption domain. If the site name in the above dispatcher receives the server’s certificate. If the 124 4th Annual PKI R&D Workshop Pre-Proceedings URL is not in the encryption domain, it is left • Certificate Interceptor: this filter grabs the unchanged. response bodies in “application/x-x509- That way, any further requests initiated by {user,ca,email}-cert” MIME types. It also looks consequences of the browser parsing the current for these content-types in each section of multipart HTML will again be sent to us – recall that the MIME types as well – this is the mechanism used engager configured us as the browser’s HTTP by web sites and commercial web-based CAs to proxy only – we do not receive any HTTPS install certificates and certificate chains. The data requests the browser generates. So this filter tries is decoded (DER/PEM-armoured detection is built to ensure that all URLs in the HTML the browser in and both single certificates and PKCS#7 bags receives point to URLs with the HTTP scheme are supported) and inserted directly to the what we can proxy. Certificate Store. The discussion omitted several details for the sake If one of the inserted certificates matches a of clarity. In our implementation, it is comprised previously sent SPKAC, the automatic attestations of two filters: a response header filter for rewriting are performed. If the inserted chain contains a URLs in the Location field during redirect Root CA but no automatic attestation has messages; and a response body filter the that occurred, a dialog box pops up informing the user parses the HTML looking for tags with src, that he/she may be interested in performing a href and action parameters and rewrites only manual attestation. URLs within them – that way, any URLs within 2.3 Engagers the readable text (outside the tags) won’t be The engagers are responsible for setting up the data touched. We also made it rewrite URLs in interception in each browser by inserting ourselves in window.open JavaScript instructions, since it the proxy chain through the following process: occurs quite often in many websites. • The browser’s current proxy settings are detected The response body filter is the system’s Achiles and saved for later restoration; heel: since it is static, it misses any absolute URLs generated dynamically by embedded languages • The address and port of the proxy the browser is such as Java, JavaScript or VBScript, nor it sees currently using for sending HTTP requests is absolute URLs embedded in Flash movies or other detected and the engager signals our default plugin-specific objects. However, things work dispatcher to use this proxy. If the browser isn’t remarkably well in sites where nearly all using any HTTP proxy, we tell our default embedded URLs are relative. dispatcher to do the same and send the requests directly; • Keygen Tag Mangler: This filter replaces the tag used by Netscape-derived • The browser’s HTTP proxy settings are overwritten with “localhost:ourport”, where browsers in web forms to generate a new keypair “ourport” is the port where we’ve previously [12] by a combo box (a started a server to listen to this specific browser’s sequence in HTML requests; parlance) allowing the user to choose one of the allowed key sizes. The original name of the • The address and port of the proxy the browser is KEYGEN tag is prepended with “x-kapanga- currently using for sending HTTPS requests is keygen-”, so that the Keygen Interceptor field detected and the engager tells the HTTPS described below can intercept it. This filter is only dispatcher to use this proxy. Unlike the HTTP active when previously told so by the command proxy, however, we don’t overwrite the browser’s parser. setting. • Keygen Interceptor: this filter acts on response Implementing this seems simple, but each browser bodies of POST requests and only when the presented its own special cases. mime-type is “application/x-www-form- The engager for Internet Explorer proved to be the urlencoded”. It looks for form fields with the simplest to implement because IE has simple API calls name starting with “x-kapanga-keygen-”. Upon to change the settings and have its currently running finding it, it starts the New Digital ID Wizard instances instantaneously reload any changes made to right in the point where the user chooses the it. Slight complications arise due to the several passphrase (see Figure 4c). When the wizard is versions of IE and the API itself. The most severe is done generating the keypair, it is converted to an with IE versions 5 and above: since it supports per- SPKAC and sent over the form field with its dialup connection profiles, each with its own proxy original name (i.e., the “x-kapanga-keygen-” settings, the process above has to be performed for previously prepended is removed). each dialup profile. In the end, the IE engager we implemented works with all IE versions all the way 125 4th Annual PKI R&D Workshop Pre-Proceedings back to version 3. Version 2 and below didn’t support A limitation of our current engager implementations is proxies at all. that they cannot handle Proxy AutoConfiguration [11], Implementing the Mozilla engager, on the other hand, which is quite popular. Since implementing this proved to be quite a challenge because of the lack of a support would require a quite capable JavaScript simple way (as far as we know) to signal its currently interpreter, we have chosen to deal with it in future running instances of any changes in its settings. versions; we felt that for the purposes of proving the Mozilla’s settings are read once during program concept, it was not essential. startup and kept in memory. We can easily overwrite Notice that engagers are just a convenience feature for the configuration files and its format is quite simple users. They’re obviously not necessary for the rest of (although figuring out where it is located means the proxy to work, so long as the user changes the messing with registry.dat /appreg file [10]). browser and Kapanga’s proxy settings manually. That This works well for inactive profiles, but not for the way, this whole system works even with browsers our active ones – the running instance doesn’t notice that implementation doesn’t have specific engagers for. All Kapanga (an external process, from its point of view) that is required is that the browser must have proxy changed the files and thus doesn’t reload them. And it support. We’ve successfully run Kapanga in overwrites our changes when saving the settings back conjunction with many other browsers such as to disk as it finishes. Konqueror, Opera and even Links (a console-based browser), just for kicks. 3 OTHER DESIGN ALTERNATIVES Before settling for the particular set of design criteria and features we described, we considered and rejected a few other alternatives. While the reasons for some of them are pretty obvious, other are quite subtle and perhaps debatable. In the next subsections we describe a few choices we had to make and the rationalie behind tem. 3.1 Traffic Interception Method Using the browsers’ native proxy support was an obivous choice – web proxy technology was Figure 8: A JavaScript program is the only way to set the proxy specifically design to intercept and forward HTTP settings in the currently running instances of Mozilla. However, traffic and it’s widely deployed and matured. Not that since changing user settings is a privileged operation, its execution we lacked choices: prompts a confirmation dialog box, somewhat thwarting the convenience of the engager. • Internet Explorer has a feature called Browser Helper Objects [15] that could make interception a The method we came up with works but is less than lot easier on that platform because we wouldn’t elegant: we generate a web page in a temporary, have to deal with next-hop proxies and its randomly-named file the local filesystem with a small particularities (PAC, multiple authentication JavaScript program that performs the changes. Then methods, etc). However, we didn’t want to confine we direct the currenly running instances of Mozilla Kapanga’s applicability to Windows only; as (via DDE [9] on Windows or X-Remote [8] protocol previously mentioned, we wanted it to work with on Unix) to open this page. Since changing those any browser on any platform; settings requires granting special privileges to the script, the first time it is run Mozilla displays a • Implementing Kapanga as a SOCKS [20] proxy confirmation dialog box, as shown in Figure 8 above. might also work, but it would involve guessing port numbers where HTTP traffic goes. Besides, The paranoid may regard this procedure as opening up not all proxies support SOCKS; a vulnerability itself – from there on, any local scripts (using the “file:///” scheme) may change Mozilla’s • Redirecting the socket API calls would not only preferences for that profile. It could have been worse, require the same port number guesswork, but it though: we considered and rejected the idea of would require a lot more system-dependent code avoiding the creation of a temporary file by sending and it wouldn’t allow Kapanga and the browsers the Javascript program over HTTP – that would mean to run on different machines. the user should allow script execution over the 3.2 The Pure-Scheme vs. Cross-Scheme Dilemma “http://” scheme, which would open it up to abusive Kapanga uses what we call a cross-scheme system: scripts from anywhere on the Internet. when a site is in the Encryption Domain, we effectively map portions of the HTTPS scheme’s 126 4th Annual PKI R&D Workshop Pre-Proceedings address space into the HTTP’s address space. That is, • Performance would suffer, since we’d have three the browser has no notion on whether the request is encryption/decryption rounds: the browser going through HTTP or HTTPS – this state encrypts the data, Kapanga would decrypt it, information is in Kapanga’s Encryption Domain. This modify it and reencrypt it again; has consequences: • It wouldn’t work on browsers without native SSL • Bookmarks made when a site is in the encryption support; in contrast, the cross-scheme approach domain will probably not work when the site is allows Kapanga to work even if the browser not in the encryption domain or when Kapanga is doesn’t support SSL; not running at all (unless the site designer was • Writing and releasing the code of a portable silent very careful to handle this); auto-engaging SSL spoofer would be more like • We had to create the URL Rewriter Filter to force giving a powerful weapon to the blackhats than a absolute URLs embedded in the HTML back to powerful protection to the average user. us. As previsouly mentioned, though, this fails Yet another advantage of the cross-scheme appoach is with dynamically generated URLs. that we give the user the choice of not using Kapanga Earlier in the design process, we considered – and at all if he/she feels like, so we neither mess nor risk to rejected – what we called a pure-scheme system: we break the user’s web banking systems and other would actually implement two proxies, one strictly critical applications they already have running. HTTP to HTTP and the other strictly HTTPS to HTTPS. Given that the namespaces don’t collide, there 4 CONCLUSIONS AND FUTURE WORK would be no need for a URL Rewriter filter nor would We described the architecture of a solution for we have problems with bookmarks. perfoming the cryptographic and user interface aspects This sounds like a good idea if we think only in terms of HTTPS channel establishment and web form of the pure HTTP proxy; however, given that SSL was signature outside of the web browser. The key idea is specifically designed to be resistant to interception and to implement the crypto services in a proxy that tampering, the pure HTTPS proxy would have to be, in rewrites the HTML on the fly and converts it to fact, a generic HTTPS spoofer/man-in-the-middle HTTPS when appropriate, so we can bypass the attack. browser’s and protocol limitations while retaining compatibility. Thus, any browser with proxy support From a purely cryptographic point of view, this is can be used – the user is not forced to adopt any quite easy to implement: during the initial SSL particular web browser. Another advantage is that our handshake, we send the browser a fake server approach does not depend on any proprietary certificate generated on the fly. From the user interface architecture such as ActiveX or Java. point of view, on the other hand, this has a problem: it triggers the browser’s SSL warning dialogs, since the Our primary motivation was to play with newer user fake certificate isn’t signed by a CA chain the browser interface concepts to make client-side PKI easier to trusts. This is clearly unnaceptable, not only in light of use. A few results stand out: in other to make sites our philosophy of non-intrusiveness and minimum with client authentication that user’s didn’t hate, we hassle for the users, but also because SSL-derived user had little choice but to address a few protocol and user interface problems are exactly what Kapanga was interface gaps: originally intented to solve in the first place. • A web site should be able to enumerate the user’s We could make the SSL spoof work silently if we certificate so as to offer assistance in registration inserted a new root certificate in each browser’s as preparation for the HTTP-to-HTTPS transition certificate store, but that would bring disadvantages: (the SSL handshake with its certificate validation first, it would again limit Kapanga to run in the same process); computer as the browser (a restriction we didn’t want • There had to be a way to redirect the user to an to have); second, the exact mechanism for inserting URL with a nice explanation, continuation options new roots varies from browser to browser: IE stores or alternative authentication methods when the trusted root CAs in the Windows Registry, while SSL handshake fails. It’s just not acceptable to Mozilla-derived browsers use a Berkeley-DB file. This break the connection and leave the user with a would increase the amount of platform-specific code cryptic error message; Kapanga would have – something we’ve been trying to • The certificate issuance process shouldn’t be so minimize all along –, not to mention that the process fragile as to break because of lack of ActiveX would fail if Kapanga runs without the proper upgrades, different browser versions or the phase privileges to write to those certstores. of the moon. Nor it should induce the user to store There are other arguments against the SSL spoofer and the private key without some effort to set up a the pure-scheme idea: decent passphrase. The process must be simple, reliable and hassle-free. Having it instantaneous is 127 4th Annual PKI R&D Workshop Pre-Proceedings a plus – with so many online services with Horacio and Theco are comic book characters from instantaneous registration processes, it is hard to Mauricio de Sousa Produções that are arguably part of justify the severe identity validation procedures of Brazilian pop culture, used here for entirely non-profit most CAs; illustration purposes. • There really should be a simple way to do such a 6 REFERENCES simple thing as signing a web form. 1. Tim Berners-Lee et al., RFC 2616: Hypertext The implementation of those features in an external Transfer Protocol – HTTP/1.1, 1999, proxy enabled us to bypass the browsers limitations http://www.faqs.org/rfcs/rfc2616.html while providing the illusion that those features were 2. Eric Rescorla, RFC 2818: HTTP Over TLS, 2000, “augmented” to the browser in an non-intrusive way. It http://www.faqs.org/rfcs/rfc2818.html also required minimal or sometimes no change to the server side at all: nothing needs to be changed for 3. Eric Rescorla, SSL and TLS: Designing and client-based HTTPS authentication; a simple change in Building Secure Systems, 2001, Addison-Wesley, the action URL in HTML forms enables form field ISBN 0201615983. signature (bigger changes may be needed if the 4. Marco Carnut, Cristiano Lincoln Mattos, Evandro application needs to validate the signatures); and small C. Hora & Fábio Silva, FreeICP.ORG: Free changes to the HTML page where the Nestcape vs IE Trusted Certificates by Combining the X.509 issuance process decision is made is enough to support Hierarchy and the PGP Web of Trust through a Web-based commercial CAs. Collaborative Trust Scoring System, 2003, The price of this “backwards” compatibility is paid in Proceedings of the 2nd PKI Research Workshop, the considerable complexity of the architecture and the http://middleware.internet2.edu/pki03/presentation horrible contortions our tool has to go about to s/02.pdf implement them. Some problems may not have a good 5. Ari Luotonen, Tunneling TCP based protocols solution at all, such as the static nature of the URL through Web proxy servers, 1998, rewriter filter not being able to handle dynamically http://www.web-cache.com/Writings/Internet- generated URLs; this limits the tool’s applicability to Drafts/draft-luotonen-web-proxy-tunneling-01.txt “well behaved” sites only. 6. Steve Lloyd et al, Understanding Certificate Path There are many worthwhile future improvements on Construction, 2002, PKI Forum, sight. Making the proxy work for generic TCP http://www.pkiforum.org/pdfs/Understanding_Pat connections as well as HTTP may help extend the use h_construction-DS2.pdf of client-side authentication for several other protocols 7. Steve Lloyd, AKID/SKID Implementation such as SMTP, POP3, VNC, X and many others. Guideline, 2002, Extending the program to act as a Mail Transfer Agent http://www.pkiforum.org/pdfs/AKID_SKID1- (since every MTA is kind of a proxy) holds the af3.pdf potential for allowing us to make the same for mail 8. Jamie Zawinski, Remote Control of Unix clients: having the digital signature generation and Netscape, 1994, verification be performed out of the mail client. Going http://wp.netscape.com/newsref/std/x-remote.html further in this idea, we could also add support for encryption and decryption to allow message 9. MSDN Library, About Dynamic Data Exchange, confidentiality. We are also working on making the http://msdn.microsoft.com/library/default.asp?url= CSM support PGP and SSH keys as well in order to /library/en- achieve Jon Callas’ concept of format agnosticism us/winui/WinUI/WindowsUserInterface/DataExch [21], consonant with our philosophy of bridging the ange/DynamicDataExchange/AboutDynamicData PKIs together. Exchange.asp 10. Daniel Wang, Mozilla Profile registry.dat File 5 ACKNOWLEDGEMENTS Format, Thanks go to our co-developer Tiago Assumpção and http://wangrepublic.org/daniel/mozilla/registry to Felipe Nóbrega for implementing both the CAs used 11. Nestcape Inc., Navigator Proxy Auto-Config File for the instantaneous certificate issuance and the public Format, 1996, CSM server. We’d also like to thank Justin Karneges http://wp.netscape.com/eng/mozilla/2.0/relnotes/d for writing the first versions of the Q Cryptographic emo/proxy-live.html Archictecture [19] on which our implementation is based. We are also grateful to the anonymous 12. Netscape Inc., Netscape Extensions for User Key reviewers for their invaluable criticisms and Generation, suggestions for this paper. http://wp.netscape.com/eng/security/comm4- keygen.html 128 4th Annual PKI R&D Workshop Pre-Proceedings 13. Arnold G. Reinhold, The Diceware Passphrase Home Page, http://world.std.com/~reinhold/diceware.html 14. Sean Smith, Effective PKI Requires Effective HCI, ACM/CHI Workshop on Human-Computer Interaction and Security Systems, 2003, http://www.cs.dartmouth.edu/~sws/papers/hci.pdf 15. Dino Esposito, Browser Helper Objects: The Browser the Way You Want It, 1999, Microsoft Corp., http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dnwebgen/html/bho.asp 16. RSA Data Security Inc, RSA Keon WebPassport, http://www.rsasecurity.com/node.a sp?id=1230 17. Verisign Inc., Go! Secure for Web Applications, http://www.verisign.com/products- services/security-services/pki/pki-security/pki- solution/web-application/ 18. John Marchesini, Sean. Smith & Meiyuan Zhao, Keyjacking: the surprising insecurity of client-side SSL, http://www.cs.dartmouth.edu/~sws/papers/kj04.pd f 19. Justing Karneges, Q Cryptographic Architecture, http://delta.affinix.com/qca/ 20. M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas & L. Jones, SOCKS Protocol Version 5, http://www.faqs.org/rfcs/rfc1928.html 21. Jon Callas, Improving Message Security With a Self-Assembling PKI, 2003, Proceedings of the 2nd PKI Research Workshop, http://middleware.internet2.edu/pki03/presentation s/03.pdf 129 4th Annual PKI R&D Workshop Pre-Proceedings Side-Effects of Cross-Certification James L. Fisher, Ph.D. Mitretek Systems, Falls Church VA jlf@mitretek.org While many organizations lean towards automatically grants that peace of mind, but cross-certification with bridge certification rather that it is standard practice for each authorities (BCAs) for wider PKI party considering cross-certification to interoperability, there are many hidden scrutinize the other party’s pre-issuance details that can affect operating capabilities identity vetting policies, private-key as well as legal standings. The purpose of protection policies, CA and directory this paper is to share lessons learned to infrastructure operational policies, etc. Thus, help the reader to understand implications an issued cross-certificate represents a of choosing a cross-certificate based trust thorough background check with acceptable model. Topics covered include: findings. X.500/LDAP certificate directory Issued cross-certificates can be used to implementation and interoperability dynamically assemble a chain of certificates requirements; transitive and asymmetrical called a trust path which spans the gap trust; choosing the proper trust anchor; between the certificate issuer and the cross-certificate policy mappings; and relying party. The complete set of Certification & Accreditation requirements. certificates comprising the certificate trust This paper does not examine the trust path path (including supporting time-specific discovery process—it focuses on the validity statements) forms a tangible record necessary, enabling configuration of trust that can be stored for future components that enable path discovery and evidence of due diligence. This might be path validation to be automated. necessary for institutional archival purposes or to satisfy National Archive and Records There are technical solutions to the issues Administration (NARA) requirements. presented herein. However, due to their inherent complexity, a discussion of alternative solutions is beyond the scope of Directory Interoperability this paper. The operating authority of a BCA typically provides a publicly available X.500 or LDAP Benefits of Certificate Bridges directory for publishing issued CA certificates, cross-certificates, and often One of the primary advertised benefits of a certificate revocation lists (CRLs). Equally certificate bridge is that it allows the relying important, these X.500/LDAP directories are party to enjoy the benefits of a larger trust configured to facilitate trust path discovery domain while not being required to be an and validation by providing chaining to, or integral part of the certificate hierarchy of referrals to, all other CA directories to which that other trust domain, all while trusting cross-certificates have been issued. The only one trust anchor—a public key which is intent is to provide a one-stop-shop virtual within its own trust domain. directory from which all relevant certificates The other benefit is that the relying party and CRLs can be retrieved during the path can also be relatively sure of the certificate discovery and validation processes. holder’s identity, based on the trust placed In practice, each cross-certifying in others to validate an organization's organization typically has its own identity. It’s not that cross-certification 130 4th Annual PKI R&D Workshop Pre-Proceedings X.500/LDAP directory to which its own The following list describes the cross- users (certificate issuees and/or employees) certifications that have occurred between point the LDAP clients in their local the above fictitious entities, and the validation engines, and if the requested resulting trust mesh appears in Figure 1: certificate or CRL does not fall under that • The Government Bridge—GBA— local directory's base distinguished name (with base DN ou=GBA, o=Upper (DN), a superior reference chains (transparently to the user) to the master Government, c=US) has cross- BCA for retrieval. No matter where the certified with only: certificate or CRL resides, it is returned to • GI (with base DN ou=GI, the LDAP client. Without such chaining, o=Upper Government, there is currently no way for a desktop c=US) LDAP client to discover what directory to • UBA (with base DN o=edu, connect to for retrieval of a certificate or c=US) CRL. This necessary processing has • Neighboring Nation (with interesting implementation implications. base DN c=NN) • The University Bridge (UBA) has First, the BCA directory must be able to also cross-certified with: resolve any base DN that could ever form a trust path through that BCA. An illustration • The original Enormous State will help in understanding the details. University infrastructure, ESU1 (with base DN o=ESU In the examples we use in this paper, Provosts, c=us) assume the existence of the following • The new Enormous State fictitious PKI participants: University infrastructure, • A Government (Certification) Bridge ESU2 (with base DN o=ESU Authority/Architecture (GBA) Provosts, c=us, dc=esu, • A Government Institution (GI) dc=edu) • A Neighboring Nation Bridge • The Neighboring Nation has also Authority/Architecture (NNBA) cross-certified with: • A University Bridge • The World Wide Council Authority/Architecture (UBA) (with base DN dc=int) • An older, legacy PKI system at the • The World Wide Council cross- Enormous State University (ESU1) certifies with: • A newer PKI system at the same • The Random Transoceanic university (ESU2) Nation (with base DN c=RTN) • A World Wide Council (WWC) • A random transoceanic nation (RTN) 131 4th Annual PKI R&D Workshop Pre-Proceedings GI GBA NNBA WWC UBA RTN ESU1 ESU2 Figure 1: Cross-Certification Between Trusting Partners Figure 1 allows us to see more clearly the • Name context: a subtree of a many and varied trust paths that can be directory, and is identified by the DN formed. For instance, through certificate of the topmost entry (the "base DN"); bridges and cross-certificates, the in many commercial databases, a Government Institution should be able to DSA's database can contain more trust digitally signed messages from the than one name context Enormous State University, regardless of • Cross-reference: specifies a name whether the signer’s certificate was issued context (usually within a remote from ESU’s old or new PKI infrastructures. DSA) that is not a child of this DSA's Additionally, cross-certificates would also name context; a cross-reference allow the Government Institution to trust typically points directly to the entry in digitally signed messages from the Random the name context hierarchy Transoceanic Nation—this trust path may or • Subordinate reference: specifies a may not be intentional or desired, as we will name context (usually within a discuss later. Let us now look at the remote DSA) that is a child of this certificate/CRL directory configurations DSA's name context required to enable a relying party to easily • Superior reference: specifies the discover and validate a trust path. parent DSA that holds entries outside this DSA; only one superior Before discussing the supporting certificate reference per DSA is permitted directories, it will be helpful to review the definition of key X.500 directory knowledge For complete directory chaining, the references and concepts: (fictitious) US-based certificate directories are configured as follows, with Figure 2 • Directory Server Agent (DSA): the representing the same information software providing the X.500 pictorially: directory service for a particular hierarchal directory information base • The GI directory DSA is rooted at (DIB) ou=GI, O=Upper Government, c=US, and has one superior reference to the GBA directory 132 4th Annual PKI R&D Workshop Pre-Proceedings • The ESU directory has: • A subordinate reference from • One DSA rooted at o=ESU the DN o=ESU Provosts, Provosts, c=us c=us to the original ESU • A second DSA (or a second directory naming context under the • A cross-reference from the first DSA) rooted at o=ESU DN c=NN to Neighboring Provosts, c=us, dc=esu, Nation's border directory dc=edu • A cross-reference from the • One superior reference to the DN dc=edu to UBA's second UBA directory DSA • The UBA directory has: • A cross-reference from the • One DSA rooted at o=edu, DN dc=int to the WWC’s c=US border directory • A cross-reference from the • A cross-reference from the DN o=ESU Provosts, c=us DN c=RTN to the RTN’s to the original ESU directory border directory • A second DSA (or a second • (no superior references) naming context under the first DSA) rooted at dc=edu (We leave it as an exercise to the reader to • A subordinate reference consider the cross-references needed at the under the second DSA from WWC and RTN border directories.) the DN o=ESU Provosts, Notice this very important fact: in order to be c=us, dc=esu, dc=edu to able to retrieve (via chaining) certificates the new ESU directory issued by RTN’s CA, the GBA directory • A superior reference to the must include a knowledge reference for the GBA directory c=RTN DN (pointing to the RTN directory) • The GBA directory has: even though the GBA did not directly cross- • One DSA rooted at c=US certify with the RTN. This requirement has • A subordinate reference from potentially serious implications on how the DN ou=GI, o=Upper easily a BCA can dynamically expand to Government, c=US to the GI accommodate indirect trust agreements. • A subordinate reference from the DN ou=UBA, o=edu, c=US to the UBA directory 133 4th Annual PKI R&D Workshop Pre-Proceedings NNBA c=NN GBA c=US cref(c=NN) cref(dc=int) cref(c=RTN) cref(dc=edu) subref(ESU Prov) o=Upr Govt o=edu subref(ou=GI) subref(ou=UBA) GI UBA ou=GI, o=Upr Govt, c=US o=edu, c=US dc=edu cref(o=ESU Prov, c=US) ou=UBA subref(ou=ESU Prov, c=us, dc=esu) ESU o=ESU Prov, c=US ou=ESU Prov, c=us, dc=esu, dc=edu Figure 2: Directory Chaining Agreements, and Subordinate and Superior References Notice that because of DN naming • cross-references conventions chosen, and how each DSA is • subordinate references rooted, both GBA and UBA directories need • superior references a cross-reference from the DN o=ESU Fortunately, these capabilities are found in a Provosts, c=us to the original ESU number of commercial X.500 directories, directory. such as: i500 by PeerLogic; eTrust by One can easily see how quickly border Computer Associates; M-Vault by ISODE. directory configuration becomes However, Microsoft Active Directory does complicated when multiple BCAs cross- not support superior references, non-local certify. Each BCA must be configured with cross-references, or non-local subordinate knowledge of all possible directories references. Therefore, organizations traversed along a trust path, even if the wishing to provide a publicly accessible BCA did not cross-certify directly with the certificate directory (often called a border corresponding CA. directory) to their relying parties suitable for use in automated path discovery should As seen, each border directory needs the export all necessary certificates and CRLs capability of supporting: from their Microsoft Active Directory and • multiple root DSAs or multiple name import into a directory supporting the contexts within a single DSA aforementioned types of references. 134 4th Annual PKI R&D Workshop Pre-Proceedings Alternatives: regulations, let us assume that GI directors would prefer that there be no valid The BCA directory was required to provide certificate trust path from GI to a multitude of cross-references and Forbiddenstan. subordinate references because directory chaining was desired. One design To prevent the formation of such a trust alternative is to have the BCA directory path, cross-certificates must be re-issued to simply return referrals to only those specify new name constraints or path length directories with which it is directly cross- constraints. There are two logical places in certified. But this presents two problems in the trust chain where such a filter could be today's environments: positioned. Since this is a federal law, the GBA’s cross-certificate issued to the NNBA • Many LDAP clients still can not could contain a name constraint to filter out process directory referrals Forbiddenstan’s c=FB DN. However, since • Trust paths traversing more than other domestic humanitarian-oriented one bridge would not be discovered government agencies might have legitimate if the pertinent certificate fields needs to trust Forbiddenstan-signed contained only DN-formatted documents, a nationwide filter might not be information and not URI-formatted appropriate. Therefore, a GI itself might information need to insert name constraints into the Directory chaining would not be necessary if cross-cert it issues to the GBA. Additionally, all certificates had properly formatted AIA all other relying parties would similarly need fields, and the local validation client could to be aware of this political situation and understand all AIA formats. However, one place appropriate name constraints in their missing or improperly formatted AIA field cross-certificates. would destroy the ability to discover a trust While this method works, it is very difficult to path. envision all necessary path constraint needs—expressed either as path permitting Transitive Trust or path inhibiting rules—before cross- When CAs cross-certify, the phenomenon of certificate issuance. And, re-issuance of a transitive trust comes into play. Such cross-certificate is not without its labor costs. indirect trust may or may not be intended or Revoking previously issued cross- welcomed. An internationally oriented certificates will also be necessary to force illustration will make the side-effects clearer. validation engines that pre-cache the validation paths to refresh themselves. Let us extend the example of the previous More importantly, the need to restrict certain section to include one additional cross- trust paths is typically not realized until after certificate pair. Assume that the very an “inappropriate” trust path is formed. recently formed country of Forbiddenstan has also cross-certified with the World Wide Choosing the Proper Trust Council for the purpose of discussing commercial trade. Consequently, there is Anchor now a new trust path from the GI, through Another challenge of a multiple cross- the GBA, through a Neighboring Nation, certificate environment is choosing the through the World Wide Council, to correct trust anchor and certificate policies Forbiddenstan. Let us also assume that on which to filter. Complicating factors "the United States maintains a broad include: embargo against trading with Forbiddenstan, and most commercial imports from • Asymmetrical policy mappings Forbiddenstan are prohibited by law.” And • The possibility of multiple trust paths finally, to ensure compliance with federal 135 4th Annual PKI R&D Workshop Pre-Proceedings • Unidirectional cross-certification mappings found in the cross-certificate (e.g., a GBA may issue a cross- issued by Algonk to the GBA, the State of certificate to a military to facilitate Algonk views GBA Medium as mapping to GBA-centric trust path discovery, but Algonk Level B. the military BCA may choose to not Typically, the trust anchor of choice is a issue a cross-certificate to that GBA) public key within one’s own issuing Policy mappings are often placed in cross- hierarchy. However, let us consider the certificates for the purpose of declaring how case were a centralized, organization- the levels of assurances (LOAs) in the independent validation service (employed subject’s domain translate to the LOAs in by a GBA) is being established to validate the issuer’s domain. In order to make use only certificates that are GBA Medium or of these policy mappings, RFC3280 equivalent. Let us examine two trust anchor indicates that path discovery and validation options and their implications. algorithms must specify a trust anchor and a If the trust anchor is a GBA root public key, set of acceptable certificate policies (in the then the certificate policy OIDs on which to trust anchor’s domain). Additionally, if the filter should be GBA Medium. In this case initial set of acceptable certificate policies is policy-filtered trust paths can be found from a subset of those mapped, then the effect is the GBA to (a) Algonk Level C certificates, to filter out any trust paths involving but not to other Algonk LOAs, and (b) any certificates with LOAs that do not map to other issuers' certificates that GBA maps to that initial set. GBA Medium LOA. Consider the following example. The Alternatively, the validation service operator (fictitious) State of Algonk has one CA (with could reason that since Algonk certificates one private key) issuing end-entity are validated so often, the dynamically certificates with one of four levels of discovered trust path for Algonk certificates assurance (LOAs): Level A, Level B, should be made as short as possible for Level C, and Level D. Independently, GSA reasons of efficiency. To shorten the trust has three LOAs: Small, Medium, and Large. path, the trust anchor is chosen to be the But when the State of Algonk cross-certified State of Algonk’s root public key. Since the with the GBA, Algonk submitted GBA views only Algonk Level C certificates documentation describing only their Level C as equivalent to GBA Medium LOA, the LOA, therefore the cross-certificate issued initial set of acceptable certificate policy by GBA to Algonk contains only one policy OIDs is just the policy OID representing mapping: Algonk Level C maps to GBA Algonk Level C. Obviously, trust paths will Medium. be found to Algonk Level C certificates. Furthermore, the cross-certificate pair However, the policy mapping in the Algonk- between the GBA and the Algonk contains issued cross-certificate (i.e., the cross- asymmetrical policy mappings. Why? certificate going in the opposite direction) Because each party’s Policy Authority (PA) states that GBA Medium maps to Algonk could independently evaluate the other Level B. Since Algonk’s Level B certificate party’s Certificate Policy/Certification policy OID is not in the initial set of Practice Statement (CP/CPS), and there is acceptable certificate policies, no other no guarantee the parties will view each issuer's certificates mapping to other’s policies equally. Consequently, GBA Medium (as determined GBA’s point of according to the policy mappings found in view) will be accepted (i.e., no valid trust the cross-certificate issued by the GBA to path will be discovered for those Algonk, the GBA views Algonk Level C LOA certificates). And the configuration decision as mapping to the GBA Medium LOA. complications increase as more BCAs Conversely, according to the policy become involved. It is therefore 136 4th Annual PKI R&D Workshop Pre-Proceedings recommended to explicitly state the browsers. validation service’s acceptable certificate For proper policy OID representation, one of policy set—and not include the phrase “or following two items must occur: equivalent”—and use only the corresponding trust anchor. • The new CR must assert all policy OIDs of all subordinated CAs, or In practice, such asymmetrical mappings can be easily avoided. Both parties should • The end-entity certificates of the explicitly state and agree on how each of subordinated CAs must be re-issued the applicant’s LOAs relates to the issuing to include the new CR policy OID party’s LOAs. Continuing with our example, Figure 3 depicts one phase of the proposed when applying for cross-certification, the hierarchy. Assume the GBA has previously State of Algonk should explicitly request that cross-certified with one of the commercial the GBA PA map Algonk’s Level C LOA to vendor’s CAs (CVCA). The root CVCA has GBA’s Medium LOA. issued a proper subordinate CA A1, and A1 issues only special-audience end-entity Post-Issuance CA certificates. These end-entity certificates, Subordination when processed through the certificate mappings in the GBA/CVCA cross- One technique for reducing the number of certificate, map to a GBA Medium LOA. certificate bridges is to establish one root Assume the common root, CR, was under which all other certificates are issued. subsequently cross-certified with the GBA. Recently, there have been discussions of establishing such a common root (CR) that Then, in the final phase, the proposed would subordinate existing commercial CAs technique for demonstrating that A1 that meet government requirements. qualifies as a Scrutinized Provider is for the CR to subordinate the CA A1. In practice, A common root would also offer the this would result in a new subordinate CA advantage of needing to distribute only one A1*. A1 and A1* have the same public key self-signed public key in popular web and subject DN (to validate the already- CR GBA CVCA A1* A1 Figure 3: Subordinating Operational CA A1 137 4th Annual PKI R&D Workshop Pre-Proceedings existing end-entity certificates issued by A1), A popular misconception in writing system but different issuer DNs. This results in two security plans (SSPs) is that when a BCA is possible trust paths from the CR root to the cross-certified with the root CA of a A1-issued certificate: certificate issuer hierarchy, the BCA PMO is required to see only the C&A report • One directly from the CR through the corresponding to the remote organization's subordinated A1* CA certificate, and root CA, and that organization can be • The second from the CR through the trusted to silently perform C&As on their CR/GBA cross-certificate, through internal hierarchy. However, a careful the GBA/CVCA cross-certificate, and review of NIST Special Publication (SP) finally through A1 800-37, "Guide for the Security Certification When processed through the second trust and Accreditation of Federal Information path, the policy mappings in the cross- Systems," reveals more stringent certificates will ensure the end-entity requirements. policies are properly mapped into the CR's SP 800-37 defines a certification agent as certificate policy OID space. However, in "an individual, group, or organization direct trust hierarchies, such as from CR responsible for conducting a security through A1* to the end-entity certificate, no certification, or comprehensive assessment policy mappings can take place. Therefore, of the management, operational, and A1-issued certificates must include two sets technical security controls in an information of certificate policy OIDs—one set for the system to determine the extent to which the CR policy name space, and the other set for controls are implemented correctly, the CVCA policy OID space—thus reflecting operating as intended, and producing the A1's two superiors. desired outcome with respect to meeting the Interestingly enough, if a relying party were security requirements for the system." given just the CR root, the subordinated A1* (p.15) Additionally, SP 800-37 states that CA certificate issued by the CR root, and an since the certification agent "provides an end-entity certificate issued by CA A1, the independent assessment of the system relying party would find a perfectly valid security plan to ensure the plan provides a hierarchical issuance path from the CR to set of security controls for the information the end-entity cert. However, if CVCA system that is adequate to meet all revoked A1 (say, due to a compromise of applicable security requirements," the A1's private key), and the organization certification agent needs to be independent behind CVCA did not notify the GBA from: Program Management Office (PMO), then • "persons directly responsible for the the above direct trust path through A1* development of the information would still appear valid when, in reality, it system and the day-to-day operation should be declared as “revoked.” of the system" Therefore, extreme caution should be used • "individuals responsible for if such a "two master" topology is used. correcting security deficiencies identified during the security Operations Policies certification" Typically, one focuses on technical and Given a certification agent's independence policy issues within one's own security from the managerial and operational chains domain. In this section we consider of a CA, the resulting report cannot remain operations policies requirements such as solely within the organizations chain of Security Certification and Accreditation command—the report must be delivered (C&A). externally. The organization most interested in and most impacted by such a 138 4th Annual PKI R&D Workshop Pre-Proceedings report is the BCA PMO, and therefore should be the recipient of the certification report. Therefore, the PMO of each BCA should regularly see the C&As of every issuing CA to which the BCA can form a trust chain. Conclusions As we have discussed, "bridging" for PKI interoperability is not the panacea that many thought it to be. It is extremely complex and requires careful attention to detail. It is easy to structure unintended and difficult-to- detect consequences. Such complexity often results in significant opportunities for undetected errors that the security community often points out as exploitable vulnerabilities. We also implore each organization to consider these inherent issues when performing security C&A and Certificate Policy/Certification Practice Statement (CP/CPS) Compliance Audits. References NIST Special Publication (SP) 800-37, “Guide for the Security Certification and Accreditation of Federal Information Systems” [http://csrc.nist.gov/publications/nistpubs/800- 37/SP800-37-final.pdf] RFC3280: “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” [http://www.ietf.org/rfc/rfc3280.txt] 139 4th Annual PKI R&D Workshop Pre-Proceedings Evaluating the Performance Impact of PKI on BGP Security Meiyuan Zhao∗and Sean W. Smith Department of Computer Science Dartmouth College David M. Nicol Department of Electrical and Computer Engineering University of Illinois at Urbana-Champaign February 2005 Abstract among parties spanning a large set of domains, these se- curity mechanisms typically rely on public key cryptog- The Border Gateway Protocol is central to making the In- raphy. Implicitly or explicitly, public key infrastructure ternet work. However, because it relies on routers from thus also becomes a critical component—otherwise, how many organizations believing and passing along informa- do the parties know what public keys to use and whether tion they receive, it is vulnerable to many security at- they are still valid? tacks. Approaches to securing BGP typically rely on pub- Neither public key cryptography nor public key infras- lic key cryptography, in various encodings, to mitigate tructure come for free. However, when designing and an- these risks; to work in practice, these approaches usually alyzing these large information-distribution systems, it’s require public key infrastructure. This cryptography and easy to overlook these implementation details, and the the PKI may both potentially impact the performance of performance impact they can have on the overall proto- this security scheme; however, evaluating how these ef- col. Furthermore, given the large, messy nature of Inter- fects may scale to large networks is difficult to do analyt- net routing, it can be hard to evaluate this impact: analytic ically or empirically. techniques may fail to capture the complexity, and empir- In this paper, we use the tools of simulation to evalu- ical techniques may require a prohibitively large testbed. ate the impact that signatures, verification, and certificate In previous work [27], we used the tools of parallel handling have on convergence time, message size, and simulation to evaluate the performance impact of basic storage, for the principal approaches to securing BGP. signing and verification on route attestations—and pro- posed and evaluated an improved way of generating and encoding this information. In this paper, we extend this 1 Introduction work: By distributing and maintaining routing information, the • to consider two new aspects of performance: mes- Border Gateway Protocol (BGP) [32, 39] plays a central sage size and memory cost; role in making the Internet work. However, BGP relies • to consider the PKI impact of recent proposals for on hearsay information. BGP speakers trust the messages in-band origin authentication; they receive and they completely trust other BGP speak- ers to follow the protocol specification reliably. Conse- • to consider the performance impact of standard PKI quently, BGP—and the Internet it routes—is vulnerable to revocation schemes; and many potential attacks by malicious players [26]. To miti- gate these risks, many researchers have proposed security • to consider the potential improvement of using re- mechanisms to authenticate the routing information trans- cent aggregate signature schemes in place of stan- ferred between BGP speakers [1, 8, 13, 17, 35, 40, 41]. dard signatures in assertion chains. S-BGP is the dominant scheme here. We find that among the half dozen techniques studied Because of the need to authenticate information passed there is no clear best solution. Compared to the technique ∗ contact author, zhaom@cs.dartmouth.edu that uses the least memory, the technique that supports 140 the fastest convergence time is three times faster but uses plicit route withdrawal, decides whether it prefers the new twice the memory. Signing cost is what matters for speed route. A withdrawal can also be an explicit announce- (and BGP convergence) but this comes at a price, memory ment, with no mention of an alternative preferred route. and message size. In this case, the recipient may examine the previously re- This Paper Section 2 reviews BGP and S-BGP. Sec- ceived routes to the same prefix and decide whether there tion 3 reviews some alternate encoding and cryptographic is an alternative to announce to its peers. If no such route approaches. Section 4 presents our evaluation methodol- found at hand, it simply withdraws the route as well. ogy. Section 5 presents our experiments and results for BGP rate-limits the sending of Update messages with path authentication. Section 6 presents our experiments parameter called the Minimum Route Advertisement In- and results for origin authentication. Section 7 reviews re- terval (MRAI), which is basically the minimum amount lated work, and Section 8 concludes with some thoughts of time that must elapse between successive batches of for future research. Updates sent to a neighbor. BGP speakers have output buffers to keep waiting Update messages, and send them in batches when reaching the MRAI. A speaker may have a different MRAI for each of its peers or may have one 2 BGP and S-BGP MRAI that controls all peers. In practice, throughout the Internet, the default value the MRAI is 30 seconds. The Border Gateway Protocol (BGP) [32, 39] is the rout- Any change of network reachability will be reflected ing protocol for maintaining connectivity between au- in the routing table of some BGP speaker. BGP will tonomous systems (ASes) in the Internet. Each AS is then propagate this change via Update messages through assigned a unique integer as its identifier, known as its the entire network, like a wave. The convergence time AS number. An AS manages subnetworks expressed as measures the length of time for such wave of announce- IP prefixes—a range of IP addresses. A BGP speaker— ments to die out completely—in other words, for the net- a router executing BGP protocol—constructs and main- work to return to a stable state. During the transient pe- tains forwarding tables that enable packet forwarding. riod of convergence, the continual changing of preferred A BGP speaker maintains connections with neighboring routes degrades the effectiveness of packet forwarding. speakers, known as its peers, and sends an Update to an- Longer convergence times thus reflect increased network nounce a new preferred route to prefix p. The route is instability and may cause severe network performance a (prefix, AS path) tuple. The AS path is a sequence problems. Studies of BGP have considered convergence of AS numbers that specifies a sequence of autonomous [10, 20, 34] and possible optimizations to control and ac- systems through which one can traverse the network; last celerate it [11, 19, 21, 23, 30, 38]. AS in the sequence is the originator of this route. For in- stance, if the autonomous system ASk owns IP prefix p, Because BGP is central to Internet functionality and is the autonomous system AS0 might send out an Update vulnerable to malicious actors, we need to secure the in- (p; {AS0 ; AS1 ; : : : ASk }) to announce its preferred route to formation that BGP distributes. We consider each compo- p. Each BGP speaker keeps received routes in its rout- nent: ing table; for each prefix, the speaker tags one route as its • Origin authentication considers whether the origi- preferred one. nating AS really controls a claimed IP address range. Typically, a speaker’s routing table changes when it adds a new route, deletes a preferred route, or replaces a • Path authentication considers whether a claimed previously preferred route with a new one. BGP speakers path to reach some IP prefix is in fact valid. incrementally send Update messages to announce such changes to their peers. When speakers establish (or re- The dominant security solution, Secure BGP (S- establish) a BGP session, they share their own routing ta- BGP) [17] focuses on the Update messages. The first step ble with each other via a large number of Update mes- of S-BGP is to set up public key infrastructures to help sages announcing routes in their routing tables. If it re- establish the authenticity of the involved parties. S-BGP sults in new preferred routes, processing of an Update uses X.509 [12] public key certificates and puts BGP- message may create a number of new Updates. If the related information into certificate extensions. Speak- speaker chooses to announce a new preferred route, it ex- ers digitally sign the Update messages they announce to tends the existing AS path by perpending its AS num- peers; with these X.509 certificates, recipients can verify ber to it and sends it to all of its peers, except the one the signatures to authenticate the received routes. who sent the route earlier. When a speaker announces More specifically, each speaker uses address attesta- a route to prefix p, it implicitly withdraws the last route tions (AAs) for origin authentication, and route attesta- it announced to p. The recipient, understanding this im- tions (RAs) for path authentication. ICANN ASes, and BGP speakers. The AS number authentication is similar to address allocation authentication. At the top, APNIC ARIN RIPE . . . AT&T ICANN assigns AS numbers to RIRs. Then, each RIR assigns some of its AS numbers and issues certificates to the third tier organizations (also called AS owners). These MCI GTE−1 . . . DSP1 AT&T Data . . . Sub1 AS owners, in turn, issue certificates for authenticated ASes. AS owners also issue certificates for BGP speaker; Sub2 DSP2 Sub3 each such certificate binds the router name to an AS num- ber and router ID, testifying that the speaker belongs to certain AS. Typical certification paths in AS number and Sub4 ... Subk BGP speaker identification PKI are as follows: ICANN “ICANN→Registry→AS owners→AS numbers” “ICANN→Registry→ISP/DSP: : : →BGP speakers”. APNIC ARIN RIPE LACNIC 2.2 S-BGP Attestations Org1, AS#s .... .... OrgK, AS#s As noted earlier, S-BGP uses two forms of attestations. ... For origin authentication, an address attestation (AA) (AS, AS#) .... (AS, AS#) establishes that an AS (the subject in the AA) is autho- rized by an organization Org x (the signer of the AA) to (Rtr, AS#, RtrID) .... (Rtr, AS#, RtrID) announce certain IP blocks of address space [17]. The origin AS sends the AA together with a certificate that Figure 1: Sketch of the S-BGP PKIs. authorizes that Org x in fact owns that IP address block. Hence, the receiver of the Update message is able to val- idate the certificate and verify the signature in this AA. 2.1 S-BGP PKIs For path authentication, a route attestation (RA) is signed by a BGP speaker to authenticate the existence and To enable validation of attestations, S-BGP proposes two position of an AS number in an AS path [17]. Figure 2 X.509 public key infrastructures. The first PKI contains demonstrates the structure of RAs. Such attestation is certificates to authenticate the owners of portions of the nested: each BGP speaker signs the AS path in sequence, IP address space. The second PKI is to authenticate BGP as it joins. That is, first the origin BGP speaker signs the speakers, ASes, and the owners of ASes. Figure 1 illus- AS number of the origin autonomous system and the in- trates the structures of these PKIs. Both PKIs are hier- tended receiver (in the form of AS number). The next archies rooted at ICANN [15]. ICANN issues itself self- signer is the receiver of this RA; it computes and signs signed certificates and further issues certificates to the the first tier of organizations, typically Regional Internet Reg- istries (RIRs) such as ARIN, RIPE, APNIC, and LACNIC. p; {3; 2; 1} p; {2; 1} S1 For the address allocation PKI, ICANN issues itself a certificate claiming the ownership of entire IP address p; {1} S1 S2 space on the Internet. Consequently, it issues certificates S 1 = {1; p; 2}K1 S 2 = {2; p; 3; S 1 }K2 S 3 = {3; p; 4; S 2 }K3 to RIRs as it assigns IP address blocks to them. The cer- 1 2 3 4 tificate contains an extension that specifies the set of ad- dress blocks ICANN is allocating to that RIR. Each RIR Figure 2: This figure sketches the process of sending route an- further assigns portions of its address blocks and issues nouncements and their route attestations. We have four ASes corresponding certificates to the third tier organizations numbered as 1, 2, 3, and 4. AS 1 initiates the process by send- of the hierarchy. The process continues until it reaches ing announcement (p, {1}) stating that it owns prefix p and it end subscribers. A typical certification path for an address is reachable. It generates the corresponding route attestation by block is similar to the following: signing {1, p, 2} using its private key K1 . It puts its AS num- “ICANN→Registry→ISP/DSP: : : →Subscribers”. ber first, then the prefix, then the intended recipient. The other ASes continue this process, except that they glue new informa- The second PKI contains certificates for AS number as- tion to the previous attestation sign the resulting blob. The figure signments, as well as identity certificates of organizations, shows the AS path components in bold. p; {3; 1} Researchers have introduced a number of optimizations for S-BGP [16], mainly focusing on caching signed and S 1 = {1; p; 2}K1 verified routes and applying DSA pre-computation. These S 30 = {3; p; 4; S 1 }K3 optimizations reduce the computational cost related to cryptographic operations in the cost of extra memory cost and computation complexity. 3 4 Figure 3: This figure sketches how S-BGP would stop an at- 3 Alternate Signature Approaches tempt by AS 3 to forge a route announcement. AS 1 had told AS 2 it would accept messages to p, and AS 2 told that to AS 3. Besides caching, other studies suggest different crypto- However, AS 3 is trying to strip away 2 and fool AS 4 into be- graphic schemes that may potentially reduce the overhead lieving a fraudulent 2-hop route. However, since AS 1 included of S-BGP route announcement authentication. We discuss the name of AS 2 in its signed statement about that link, AS 4 three: signature amortization, sequential aggregate signa- will detect the forgery. tures, and origin authentication. the concatenation of the previous RA, the newly appended 3.1 Signature Amortization AS number, and intended receiver. The process goes on until the entire AS path is signed. In our previous analysis [27], we proposed Signature The inclusion of the intended recipient and the prefix Amortization (S-A). in each signature is necessary to prevent against “cut-and- Looking at the details of the path authentication pro- paste” attacks. To continue the earlier example, consider cess, we observed two important facts. First, BGP speak- Figure 3. AS 3 is not able use the attestations it has re- ers verify RAs more often than creating RAs themselves. ceived to forge an attestation for route (p, {1,3}) that AS Hence, making verification faster could potentially de- 4 will accept. To do so, AS 3 would need a signed state- crease the overall computational latency. Second, when ment from AS 1 offering to route information to p directly the BGP speaker sends identical routes to its neighbors, it from AS 3. However, the signed link that AS 3 has from has to create distinct RAs; moreover, BGP speakers keep AS 1 explicitly specifies that AS 1 links to AS 2, not AS outgoing Update messages in buffers and, using MRAI 3. To facilitate validation, BGP speakers send the new timers, send them in bulk. This bulk send creates the po- RA together with all the nested RAs associated with it. tential for getting more “bang” from each private key op- This way, the receiver can authenticate the entire AS path. eration. However, receivers need certificates for BGP speakers to Our S-A scheme exploits these two facts. To speed up validate these signatures. the verification processing, we use RSA, since RSA veri- fication is significantly faster than DSA (used by S-BGP). 2.3 Performance Issues of Path Authentica- Then, we amortize the cost of signing operation in two steps. tion In step one, when a BGP speaker sends the same route Several factors affect the performance of path authentica- announcement to multiple recipients, we collapse it to lit- tion in S-BGP, given the structural properties of RAs. erally the same announcement—using a bit vector (or a First, BGP speakers consume extra CPU cycles when more space-efficient equivalent) to express which of the signing and verifying RAs and when handling and validat- speaker’s peers are the recipients. Thus, the speaker only ing certificates. Each Update message involves one sign- needs to generate one signature, instead of one for each re- ing operation by each signer and k verification operations cipient; the verifier of this RA uses the bit vector to check by each verifier (where k is the number of RAs for this AS the intended receiver. To do this, the speaker needs to pre- path). Moreover, for each signature verified, the verifier establish an ordered list of its neighbors, and distribute needs to validate the certificate of the alleged signer. Sec- this to potential verifiers; however, we can put this infor- ond, RAs and certificates increases message size. Each mation in the speaker’s X.509 certificate, since the verifier message with an AS path of length k carries k nested RAs. needs to obtain that anyway to verify the signature itself. Finally, to decrease the number of signing/verification op- In step two, when its MRAI timer fires and a BGP erations, one could cache the signed or/and verified routes speaker sends the messages accumulated in its out buffers, in memory. Therefore, memory cost becomes another is- we have it collect all “unsigned” messages, build a Merkle sue. hash tree [24, 25] on them, and signs the root of the tree— thus generating one signature for all unsigned messages, In the Aiello OA scheme, the BGP speakers send or- instead of one for each. A leaf of the tree is the hash of the dinary BGP Update messages together with origin au- pair of a route and its recipients. The resulting RA con- thentication tags (OATs). Each OAT contains a delegation sists of the RSA signature on the root, the the hash path path, a set of delegation attestations (one for each edge in from the root to that leaf, the route, and the recipient bit the path) and an ASN ownership proof. The structure of vector. A verifier of the RA can use these hash values and a delegation attestation is similar to an S-BGP address al- information in the route announcement to construct the location certificate. The signer authorizes that the subject root of the tree correctly. There are trade-offs, however. is delegated some address blocks as recorded in an exten- The verifier needs to perform a few extra hashing opera- sion. The ASN ownership proof is a certificate issued by tions when verifying a RA, and the message size grows ICANN; it attests that some AS numbers are granted to a (due to the hash path). particular organization. With our S-A approach, we speed up the security oper- The OA scheme considered four possible constructions ations of S-BGP at the cost of more memory and longer on delegation attestation. A Simple Delegation Attesta- Update messages. tion contains a signature by an organization on a tuple (p, org), where p is the prefix delegated to org. An Authen- tication Delegation List combines all (p, org) tuples by 3.2 Sequential Aggregate Signatures the same organization into single list and generates one signature. A compromise of these two approaches, an Recently, aggregate signature schemes have emerged that AS Authentication Delegation List breaks up the long list save signature space when multiple parties need to sign into several sublists (each containing the delegation tuples messages [2, 3]. The sequential aggregate signature specifying the address delegations made to the same or- (SAS) scheme by Lysyanskaya et al. [22] combines n sig- ganization and autonomous system) and signing each. An natures from n different signers on n different messages Authentication Delegation Tree constructs a Merkle hash into one signature of unit length. In SAS, each signer, in tree on an organization’s delegation list, and signs the root an ordered sequence, incrementally signs its new message of the tree. We denote these variations by the terms OA- and incorporates it into the aggregate signature . A party Simple, OA-List, OA-AS-List, and OA-Tree, respectively. with knowledge of the n messages, the public keys of the n ordered signers, and the final is able to verify that each signer si has correctly signed his message Mi and 4 Evaluation Methodology is a valid sequential aggregate signature. The major ad- vantage is that the signature of n messages is the same asAs Section 1 notes, this paper reports research examining the length of an ordinary signature. Furthermore, an SAS the performance impact of public key cryptography and scheme can be built from RSA, with small modifications, public key infrastructure on BGP security. Section 4.1 easing implementation. describes the metrics we use. Section 4.2 describes the Applying SAS scheme to path authentication of S-BGP, various BGP security approaches on which we take these we generate along the AS path similar to nested RA measurements. Section 4.3 discusses the tools we use to signatures. Since one aggregate signature is enough to carry out these experiments. authenticate entire AS path, this scheme shortens message size. 4.1 Performance Metrics 3.3 Origin Authentication We use a set of metrics to evaluate performance in terms of time and space. Aiello et al. [1] consider the semantics, design, and For time, we measure the number of cryptographic op- costs of origin authentication in BGP, and propose an OA erations involved, the resulting CPU cycles, and the BGP scheme. convergence time: the time it takes the system to re- The authors formalize semantics for IP address dele- achieve a stable state after a perturbation, such as a new gation, which is similar to the address allocation PKI by route announcement, a route withdrawal, or a router re- S-BGP. The proofs of the IP address ownership establish boot. For each security scheme, we compare its con- a tree-like hierarchy rooted at IANA [14]. The next tier vergence time with convergence time that original BGP are the organizations that receives /8 IPv4 address blocks achieves for the same perturbation. (Given the distributed directly from IANA. These organizations further delegate nature of BGP, convergence time is very difficult to be sub-block addresses; delegations continue until we reach predicted using analytical techniques.) autonomous systems. For space, we measure both the message size and the storage cost in memory. Similar to other studies, our ex- Convergence Message Size Memory periments relax the current BGP maximum transfer unit S-BGP long moderate best (MTU) (4096 bytes) limitation, to be able to understand S-A shortest worst worst the efficacy of any possible optimization. SAS longest best best Table 2: Performance rankings for the path authentication 4.2 Experimental Approaches schemes we examined Our previous work evaluated the time impact of S-BGP and S-A on path authentication. We now measure the its peers, via a large amount of route announcements. To space impact as well, and both space and time impacts of maximize the effects, we let the rebooting BGP speaker to SAS on path authentication. We measure the time impact be the one with the most peers. of CRL and OCSP revocation schemes on fully optimized Besides the common settings, we also have specific S-BGP. parameters for each of the security schemes. Table 1 We also examine the origin authentication scheme of summarizes the benchmarks and measurement numbers Aiello et al. We measure time and space impacts of all we use in our simulation. The running time benchmarks four variations, as well as the time impact of CRL and of cryptographic operations are from OpenSSL [29] li- OCSP revocation on the OA-AS-List variation (since it’s brary. For those algorithms not directly implemented by the closest to S-BGP origin authentication). the library (such as DSA pre-computation, SAS aggre- gate signing and SAS aggregate verification), we decom- pose the involved operations and sum up the benchmarks 4.3 Simulation of each step as an estimation. In addition, the numbers are normalized to a 200MHz CPU, which is a common We use discrete-event simulation to understand the perfor- CPU speed of BGP routers. We use a real system to mea- mance of BGP origin and path authentication schemes in sure and estimate latencies of processing plain Update a large-scale environment. As with our earlier work, our messages, of sending a OCSP request and receiving a re- experiments uses SSFNet [5, 28], a discrete-event simu- sponse, and of fetching CRLs. To take into account other lator that provides a comprehensive model of basic BGP factors that could potentially affect the numbers, the simu- operations [31]. Our earlier work added hooks for variants lation decides these values by uniform distribution within of processing models of BGP security schemes [27]. certain ranges. S-BGP studies [16, 18] give the numbers Throughout this study, we evaluate security schemes in for sizes of S-BGP certificate and attestations. the same network topology and same BGP activity set- tings. We use a 110-AS topology, with one operating BGP speaker per AS. For modeling simplicity, each BGP 5 Path Authentication Performance speaker announces two prefixes. In our model, each AS also possesses virtual BGP speakers that don’t actually Analysis run a simulated BGP protocol. We use the number of such BGP speakers to represent the size of an AS; its size af- We compare performance impact of S-BGP, S-A, and fects the time it takes for one Update message to be prop- SAS. We examine the performance on signatures and agated through an AS. PKIs respectively. This section gives detailed results and analysis. We use the public data provided by RouteViews project [33] to generate a graph of AS connectivity of the Internet, then reduce the size to 110 ASes using a col- 5.1 Signatures and Verifications lapsing procedure. This reduced graph still preserves cer- tain macroscopic properties [6] seen on the entire Internet. Before examining details, we enumerate our major find- Moreover, we incorporate our estimation of route filtering ings on convergence time, message size, and memory cost policies into the topology using a method, similar to the in Table 2. S-BGP performs badly on convergence time, one proposed in [7]. but is fairly efficient on memory cost. S-A outperforms During normal BGP activities, we let one BGP speaker the other two on convergence time, but is significantly crash and reboot. We evaluate the performance of the en- more costly than the other two schemes on message size tire system during router rebooting process. The work- and memory cost. SAS generates the shortest Update load on BGP speakers could be much higher than normal messages, but results in the longest convergence time. BGP activities, since the rebooting BGP speaker receives We also studied the efficacy of strategies for caching routing table dumps in a short period of time from each validated (or generated) signatures. In simulation experi- SHA-1 hash MD5 hash Attestation S-BGP X.509 Certificate Identifier Length (bytes) 20 16 110 600 4 RSA DSA DSA (p-c) SAS Verify Time (ms) 2.5 31.0 31.0 2.5 Sign Time (ms) 50.0 25.5 0.015 50.0 Signature Length (bytes) 128 40 40 128 OCSP request CRL fetching Operation Latency (second) 0.5–1.0 0.5–1.0 Table 1: Constants and benchmarks used for simulation. RSA, DSA, and SAS algorithms are based on 1024-bit keys. ments, we explored S-BGP with several variations of DSA including signing, verification, and hashing (“crypto,” optimizations. For the presentation of experiment results, in Figure 6). SAS requires 1723:2 seconds extra time we use cDSA to denote S-BGP with caching, pDSA to for aggregate signing and aggregate verification, which is denote S-BGP using DSA pre-computation, and cpDSA much shorter than 4002:2 seconds by S-BGP. This dif- for S-BGP with both optimizations. In our model, these ference results mainly because aggregate verifications are caching strategies store both validated signatures and gen- much faster than DSA verifications. Caching optimization erated signatures; we use 10 s (with a uniformly dis- to S-BGP and SAS scheme can significantly reduce total tributed delta of 5 s) to model the lookup time. The S-A CPU time. Although S-BGP (pDSA) uses much faster scheme will not speed up by caching hash trees with sig- signing operations, the net speed-up is limited, because natures, because the trees, and hence the signatures, are the number of verification operations dominates the num- constantly changing even for the same route announce- ber of signing operations. Compared with S-BGP and ment (since the trees depend on the context of what else is SAS, S-A improves both aspects—fewer signing opera- being signed at that time). Therefore, we only examined tions and faster verifications. Our experiments confirm it S-A scheme without caching, when studying processing is the most efficient on CPU cycles. latency and convergence time. However, we model a spe- Next, we look at convergence time. Among the three cial variation for S-A caching merely to understand po- major schemes, SAS is the worst. Compared with plain tential memory cost it might result. Finally, all the ex- BGP, it converges three times slower. S-BGP comes next, periment results are average numbers from 20 runs of the with a slowdown of about 2.3 times. Even with optimiza- simulation. The standard deviation is less than 5%. tions, S-BGP still takes 46:05% longer to converge. (Our previous work [27] showed better S-BGP numbers, but that turned out to be due to a bug in our simulation code.) Time We examine the convergence time by looking at Such slowdowns lead to routing fluctuations that create the counts of cryptographic operations. Figure 4 through all sorts of network problems, such as increased packet Figure 7 summarize the results. All the schemes without loss rates, increased network latencies, increased network caching optimization generate relatively the same number congestion, and even disconnections. In our experiments, of signature verifications, proportional to the total num- ber of AS numbers encountered in AS paths in route an- nouncements. Similarly, caching optimization by each of 120,000 the schemes achieves relatively the same number of sav- 110,923 112,201 101,947 111,449 ing percentage. 100,000 The story of signing operations remains the same for 80,000 S-BGP and SAS schemes. The S-A scheme can dramat- ically save as many as 98:3% of signing operations. Our 60,000 experiments show that the average hash tree size by S-A 40,000 is about 60:1, indicating that S-A is able to amortize the 24,826 33,216 24,181 cost of 60 signing operations into only one signing and a 20,000 few hashing operations. 0 The CPU cycles and convergence time reflect this dif- S-BGP S-BGP S-BGP S-BGP S-A SAS SAS ference in the number of cryptographic operations. We (DSA) (cDSA) (pDSA) (cpDSA) (caching) sum up the total CPU time on all BGP speakers, and also track the portion consumed by cryptographic operations, Figure 4: Verification operations in path authentication 25,000 700 22,072 22,465 22,303 600 20,000 500 Time (seconds) 15,000 400 11,862 11,522 12,035 300 10,000 200 5,000 100 350 0 BGP S-BGP S-BGP S-BGP S-BGP S-A SAS SAS 0 S-BGP S-BGP S-BGP S-BGP S-A SAS SAS (DSA) (cDSA) (pDSA) (cpDSA) (caching) (DSA) (cDSA) (pDSA) (cpDSA) (caching) Figure 7: Convergence time in path authentication Figure 5: Signing operations in path authentication Memory Figure 8 shows the average memory cost and maximum memory cost for individual BGP speakers. We router reboots by BGP even without any security protec- start with a baseline of 9KB memory at each speaker, for tion already cost the network 153:7 seconds to converge. plain BGP. On average, S-BGP increases this requirement Extending the period to another several minutes is not a to 112:25KB, SAS to 121:95KB, and S-A to 314:38KB. good option. We assume that BGP speakers record all cached routes Fortunately, our S-A scheme increases the convergence in memory (e.g., RAM). In the simulation, we count the only by a few seconds, with no burden on caching large bytes of the IP prefix, AS path, and related cryptographic amount of data in memory. data structures (signatures, hash values, and bit vectors). Our experiments revealed that, counter-intuitively, con- As mentioned earlier, frequent changes of hash trees vergence time is not proportional to the CPU time spent prevent S-A from saving processing latency by caching by BGP speakers. In fact, the data suggests that the la- signatures. To explore the memory impact of caching, tencies in the message sending process (therefore, sign- we tried letting S-A cache more stable data, the leaf in- ing overhead) could be the dominant factor. For instance, formation: Update messages, signatures, and associated if we consider only the CPU time consumed by signing bit vectors (assuming neighboring relationship between operations, SAS costs the most, about 92% of the total ASes stays unchanged during simulation). For this ex- CPU time, which could explain why SAS is the slow- periment, we dispensed with hash trees, but the resulting est on convergence. One might reach a similar conclu- convergence time of a variant that used hash trees and this sion from the inconsistency between S-BGP (cDSA) and caching would not be worse than the numbers shown in S-BGP (pDSA). Although S-BGP (pDSA) requires more Figure 7 and 8. CPU cycles, almost all of these CPU cycles are spent for One of the leading factors that affect this memory cost signature verifications. As the result, it converges faster. 450 Average 400 Maximum 4,500 350 314.38 Basic 300 4,000 Kilobytes Crypto 3,500 250 Time (seconds) 3,000 200 2,500 150 121.95 112.25 2,000 100 1,500 50 9.02 1,000 0 BGP S-BGP S-A (variant SAS 500 (cDSA) with caching) (caching) 0 BGP S-BGP S-BGP S-BGP S-BGP S-A SAS SAS (DSA) (cDSA) (pDSA) (cpDSA) (caching) Figure 8: Comparison of memory costs for caching. The S-A scheme in this comparison is a variant that does not use hash Figure 6: Total CPU time in path authentication trees, and caches leaf information instead of signatures. BGP S-BGP S-A SAS 5.2 Certificate Revocation Average message 36.09 318.61 1107.08 184.29 Bringing the PKI one step closer to reality requires con- size (bytes) sidering the costs of checking the validity of a signer’s Increase 8.83 21.57 5.11 certificate, when verifying a signature. Recall that BGP Maximum speakers use their private keys to sign and create RAs on message 42.6 527.7 1915.4 191.2 route announcements. We use simulation to model the size (bytes) case that BGP speakers validate BGP speakers’ public Increase 13.77 47.75 4.40 keys in certificates before using them to verify RAs. Table 3: Message size. The increase numbers are based on the In our revocation simulation, we assume that the 110 message size by original BGP. ASes belong to different organizations (also called PKI domains), with each organization having its own CA issu- ing certificates for that organization’s BGP speakers. Each PKI domain has a repository of certificates, offered by is signature length. Here, S-BGP outperforms S-A be- an LDAP server. When we model revocation by OCSP, cause a DSA signature is much shorter than a RSA signa- we assume an organization has an online OCSP respon- ture (e.g., 40 bytes vs. 128 bytes). Secondly, SAS is able der; when we model CRLs, we assume the organization’s to save memory by caching only one signature for an AS LDAP server also offers CRLs. path of any length. Even with RSA signatures, SAS is as We then examine the convergence time for S-BGP with efficient as S-BGP. all optimizations, using OCSP or CRLs for certificate val- Although not shown in Figure 8, edge routers consume idation. The OCSP approach provides fresh information the most memory for caching routes, statistically. We of certificate status, at the cost of network and process- posit two reasons. First, as a pure customer in the net- ing latencies. The CRL approach is less aggressive: the work, an edge router may receive more route announce- verifier downloads CRLs periodically, checks certificate ments than the ones in the core of the network. Sec- status with these local copies, and (when the local copies ond, and most importantly, the AS paths recorded by edge expire) get fresh CRLs from the appropriate repositories routers are significantly longer, so these routers will cache via the LDAP protocol. more signatures. For simplicity, we assume that BGP speakers can vali- In ongoing work, we are exploring using cryptographic date OCSP responses and fetched CRLs by verifying sig- hashing to further reduce cache size. natures on them. In other words, we do not model the process of discovering trust path for them. The rest of this section discusses and compares the performance impact that checking certificate status has on S-BGP. Update Message Size SAS produces one signature for an AS path; it wins the competition on message size. S- OCSP The model we use to study OCSP is close to typ- BGP is next, again, because of shorter signature length. ical PKI practice in the real world. In a practical PKI, one Our experiment results, shown in Table 3, confirm that S- or more OCSP responders connect to a certificate database A generates the longest messages. For both S-BGP and S- operated by local CAs to serve the status information of A, number of signatures in messages grows as the length the certificates issued by local CAs. Optionally, the re- of path increases. sponders can set up SSL connections to enhance privacy For SAS, since each Update message contains only one for the client. aggregate signature for the entire AS path, the maximum The OCSP response is a signed data structure that con- message size is close to the average size. On the other tains the real-time status of a requested certificate. OCSP hand, the longest Update message for the S-BGP and S-A introduces latencies, from setting up an SSL connection, schemes is about two times as long as average messages. from network delays, from real-time signing, and from Our experiments measured shorter message sizes than signature verification. According to measurements we the number measured in the Internet, because we only made with real-world OCSP implementations, the latency considered the fields (AS path, signatures, hashes, and bit of one round is about 0:5–1:0 seconds, the majority of vectors) that would vary between the schemes. Since the which is from network latency. ignored portions are the same for each of the schemes, the If a client has multiple certificates to validate, it can simulation still results in a fair comparison of the message send OCSP requests in sequence or in parallel. A proxy, size. such as a Certificate Arbitrator Module (CAM) [37], can Protocol # Ann. # Vrf. # Sign # OCSP Rqst. Basic CPU (s) Crypto CPU (s) Convergence (s) BGP 19571.8 – – – 1310.6 – 153.7 S-BGP (cpDSA) 21898.9 24180.6 11521.9 – 1464.1 755.4 224.4 Sequential OCSP 22542.9 113859.9 11663.2 89912.5 1501.7 70990.2 2720.4 Parallel OCSP 21707.8 110429.3 11290.5 87004.0 1448.5 3971.0 344.3 Table 4: Performance of validating certificates using OCSP for S-BGP path authentication contact multiple OCSP responders throughout the net- net using such semantics. Using publicly available Inter- work and send requests in parallel for the client. In our net measurements, these researchers generated an approx- simulation, we model both sequential and parallel cases. imated address delegation graph, a tree rooted at IANA. Table 4 shows that checking certificate status using The structure is very similar to the address allocation PKI OCSP for S-BGP is intolerably expensive. Sending se- by S-BGP (not surprising, since it essentially solves the quential OCSP requests is an especially bad idea. We put same problem). performance numbers of BGP and S-BGP (cpDSA) in the For each prefix in route announcements, the Update table for comparison, and show both the basic CPU time, message should carry an address delegation path for au- the processing latencies related to cryptographic opera- thentication. The scheme of Aiello et al. [1] uses in-band tions, the latencies by OCSP requests and responses, and address delegation attestations carried in Update mes- network latency in between. Even the resulting conver- sages, because these attestations are much smaller in size gence time for parallel OCSP requests is 344:3 seconds. than the S-BGP address allocation certificates. We use simulation to re-visit this issue. CRLs For CRLs, we assume that each BGP speaker has We model address delegation using this approximated a local cache of CRLs. Since signature verification re- complete graph of the Internet and size it down so that quires an up-to-date copy of the CRL from the relevant it is suitable for our 110-AS simulated network. In prac- CA, the BGP speaker pays the price of fetching and vali- tice, ASes could announce many prefixes, each of which dating fresh ones before verifying RAs, if some CRLs are could have its own address delegation path in the graph. missing or expired. Our simulation model is much simpler; each AS only an- nounces two prefixes. We add randomness in the model To evaluate the cost of fetching CRLs, we let BGP to capture the diversity of the real world. First, we put the speakers have a certain fraction of the CRLs in their local address delegation graph into the configuration of simu- cache be expired, and then measure the resulting conver- lation, so that BGP speakers can recognize all delegation gence time. The experiments assume that it costs 0:5–1:0 paths for each origin AS. Next, we let BGP speakers ran- seconds on average for BGP speakers to fetch a CRL. We domly choose a path for the prefix based on the origin AS. also assume that CRLs are valid for 12 hours. We limit the path length to seven (since address delegation Figure 9 shows the measurement data from simulation. paths are reported to be no longer than 4-5, in practice). It is clear that more expired CRLs cause the convergence times to increase linearly. These times range from 224:4 seconds to 287:7 seconds. Hence, even with all CRLs ex- 290 pired, validating certificates against CRLs is still a more 280 convergence time (seconds) efficient approach than OCSP, which costs 344:3 seconds to converge with the fast option, parallel OCSP requests. 270 260 6 Origin Authentication 250 Our approach to studying origin authentication is similar 240 to the approach we took for path authentication. We first 230 look at the performance impact of signatures and verifica- tions, then examine the certificate validation cost on top of 220 0 20 40 60 80 100 120 that. We add one model in simulation for experiments— Number of Expired CRLs the approximated address delegation graph. As mentioned earlier, the semantics of IP address delegation start from Figure 9: Convergence times by S-BGP using CRLs to validate IANA. Aiello et al. [1] expressed IP addresses of the Inter- certificates. 50,000 200 45,000 180 46,009 40,000 160 35,000 140 Time (seconds) 120 30,000 100 25,000 80 20,000 15,429 60 15,000 10,518 10,519 40 10,000 20 5,000 0 BGP OA- OA- OA-AS- OA- 0 OA-Simple OA-List OA-AS-List OA-Tree Simple List List Tree Figure 10: Number of verification operations by OA address Figure 12: Convergence time by OA address delegation attesta- delegation attestation constructions. tion constructions. This randomly chosen path determines what address del- tion verification possible. However, as Aiello et al. also egation attestations are involved. mention, in-band delivery of delegation attestation is sus- ceptible to replay attacks, unless we introduce short-lived tokens or make delegation attestations short-lived. Thus, 6.1 Signatures and Verification a trade-off exists between the period of vulnerability and the overhead of administration and computation. Time Figure 10 through Figure 12 show the processing latency. We assume that organizations prepare the delega- Memory We let BGP speakers cache verified attesta- tion attestations offline; the simulation only counts signa- tions and associated prefixes; we then measure the aver- ture verifications and hashing latencies accordingly. The age memory cost and message size. Table 5 shows that OA-List and OA-Tree approaches greatly reduce the num- the OA-List scheme is more costly than other schemes, ber of signature verifications required. Compared with mainly because the list construction produces extremely path authentication schemes, the increase of convergence long delegation attestations. In the approximated address time by all delegation attestation constructions are man- delegation graph, the average number of delegations made ageable. This result, again, implies the verification over- by organizations is about 56:96. Moreover, about 16 or- heads are a minor factor to convergence time compared to ganizations make 80% of the address delegations. Obvi- signing operations. ously, this graph has high connectivity and the delegations The resulting convergence time of OA confirms the are concentrated on very small portion of organizations. conclusion made by Aiello et al. [1]—the efficiencies af- These features are the reason why the AS-List approach forded by OA designs make in-band delegation attesta- can produce long lists of prefixes in address delegation at- testations. According to Figure 10, the AS-Tree approach handles the least number of signatures; however, its mem- 1,600 ory cost and message size are worse than OA-AS-List, 1,400 Basic mainly because the AS-Tree approach involves hash val- Crypto ues, which are much longer than organization identifiers. 1,200 Time (seconds) 1,000 800 6.2 Certificate Revocation 600 The above analysis shows that the OA-AS-List attestation 400 construction is fairly efficient. It is the most efficient one 200 on memory cost and message size, and it does not put 0 significant pressure on BGP processing and convergence. BGP OA- OA- OA-AS- OA- Simple List List Tree In fact, the OA-AS-List construction—the delegation list grouped by different delegatees—is very similar to the de- Figure 11: Total CPU time by OA address delegation attestation sign of address allocation certificates of S-BGP. Thus, we constructions. next consider the case that BGP speakers send S-BGP ad- Attestation Constructions OA-Simple OA-List OA-AS-List OA-Tree Storage for Attests. (KB) 42.80 666.27 13.23 30.22 Message Size (Bytes) 496.97 36293.37 575.35 1029.24 Table 5: Average memory cost and message size by OA address delegation attestation constructions. 210 6.3 Certificate Distribution 200 In addition to processing latency and convergence time, 190 the experiments also measure message size. Carrying cer- tificates in Update messages would require 2KB on aver- seconds 180 age. The maximum message size about 4KB. Given the BGP message MTU, carrying these certificates does not 170 appear to be feasible in practice. On the other hand, if BGP speakers record all certificates locally, our simula- 160 tion shows that certificates consume about 6KB storage on each BGP speakers, on average. The relatively small 150 0 20 40 60 80 100 120 scale of the simulated network prevents us from directly Number of Expired CRLs inferring potential storage issues in the real world. IP ad- dress allocations, AS number assignments, and router as- Figure 13: Convergence times by origin authentication using signments on the full Internet produce much more certifi- CRLs to check certificate status. cates. The CIDR BGP report from AS1221 (Telstra) [4] shows that there are 181,031 active BGP entries in a rout- ing table. To validate ownerships of these prefixes, we dress allocation certificates, instead of delegation attesta- need roughly the same number of address allocation cer- tions in Update messages. In other words, the sender en- tificates. Besides, this report also concludes that there closes the complete certification chain for the verification are about 18,233 unique ASes and 50,000 organizations. of address attestation (AA). We assume that each speaker Considering both PKIs by S-BGP, each BGP speaker sets ICANN and the CA in their local PKI domain as its needs about 190MB in total to store all certificates. trust anchors. Again, bringing this PKI one step closer to reality re- quires considering the costs of checking the validity of the certificates. We consider each approach in turn. 7 Related Work The performance studies in [16, 18] offer detailed discus- sions on deploying S-BGP in the real world. The authors OCSP As before, we first consider OCSP, both in se- collected a variety of data sources to analyze S-BGP’s per- quence and in parallel. Table 6 shows the experiment formance impacts on BGP processing, transmission band- results on processing latency. The most important con- width, and routing table size. These studies concluded clusion we can draw is that, as for path authentication, that the memory requirements of holding route informa- OCSP processing for origin authentication can greatly tion and related cryptographic data are a major obstacle to slow down the BGP convergence. For either part of BGP deployment of S-BGP. Unlike our work, all of the discus- route authentication, using OCSP to validate real-time sions are based on static measurement of BGP. certificate status does not appear to be feasible in practice. The origin authentication study by Aiello et al. [1] de- signed a simulator, OASim, to model the operations of a single BGP speaker. This simulator accepts timed BGP CRLs Again, we carried out experiments assuming dif- Update streams and computes the costs associated with ferent sets of CRLs expire at the routers, and examined the validation and storage of the related origin authentica- performance. Figure 13 shows the results. The curve tion proofs. The simulation results show that in-band dis- is similar to the convergence time by path authentication tribution of origin authentication proofs is possible. Our with CRL fetching. The convergence time is relatively un- simulation is more powerful than OASim in that we model affected if each of the BGP speakers needs to fetch fewer and simulate a network and study the convergence time. than eight CRLs during rebooting. Our previous study [27] used a packet-level detailed Protocol # Ann. # Vrf. # Attest. # OCSP Rqst. Basic CPU (s) Crypto CPU (s) Convergence (s) BGP 19571.8 – – – 1310.6 – 153.7 OA-AS-List 20131.2 15429.1 10364.1 – 1349.7 480.4 155.1 Sequential OCSP 22800.5 73586.7 5071.0 68515.65 1522.1 53665.7 2420.9 Parallel OCSP 22408.6 72635.2 5071.2 67564.00 1494.8 19060.2 938.7 Table 6: Convergence impact of OCSP on in-band address attestation. simulation model of BGP to understand the processing 8 Conclusions overhead by S-BGP. We discovered that, due to public key cryptography, S-BGP is expensive on operational latency Implementation details of securing BGP have signifi- and thus greatly increases convergence time. We further cant impact on BGP’s behavior, and on the capacity of proposed a more efficient scheme (signature amortization, routers to actually use the algorithms. BGP’s detailed S-A) for BGP path authentication. Our simulation experi- time and memory consumption is too complex to analyze ments conclude that the new approach has minimal impact purely with mathematics, and so we turn to large-scale on BGP convergence. discrete-event simulation to examine the impacts of cryp- There are also other studies on more efficient mecha- tographic operations and standard PKI certificate valida- nisms for securing BGP. One challenge in the adoption tion schemes on recent proposals to secure BGP. of any inter-domain routing security solution is its inte- We compare several major security proposals with S- gration with existing infrastructure. In the Inter-domain BGP. Our simulation results have shown that it is pos- Routing Validation (IRV) project [8], participating ASes sible to apply more efficient cryptographic operations to host servers called IRVs. Each IRV maintains a consistent improve the performance in terms of convergence time, corpus of routing data received and advertised. Remote message size, or storage costs. Tradeoffs exist. Different entities (e.g., routers, other IRVs, application) validate lo- proposals have their own strengthens and weakness. In cally received data by querying source AS IRVs using an particular, Signature Amortization achieves fast conver- out-of-band (and potentially secure) protocol. This ap- gence at the cost of longer message size and more mem- proach has the advantage that the query responses can be ory. Sequential Aggregation Signatures can decrease the tailored to the requester for optimization or access control. message size, but slowing down the BGP convergence sig- A recent effort that attacks the scalability issue of S- nificantly. The Origin Authentication scheme can achieve BGP is psBGP [40]. The major goal is to increase prac- instant origin proofs with in-band distribution of attesta- ticability of security solutions on BGP. The psBGP pro- tions, at the cost of exposing vulnerabilities to attackers. tocol contains four main components—authentication of We also analyzed the impacts of standard certificate AS numbers, authentication of IP prefix ownership, au- revocation/validation mechanisms. The OCSP approach thentication of BGP speakers, and integrity of AS path. greatly slows down convergence. On the other hand, if Essentially, this proposal combines aspects of S-BGP and BGP speakers rely on CRLs for certificate validation, the soBGP. extra overheads by CRL handling operations are insignif- Besides public key cryptography, there are efforts on icant to affect convergence. Of course, such choices trade securing BGP using symmetric key algorithms [9, 13, 42]. performance with security. These proposals are more efficient on the operational la- Besides BGP routing system, a variety of other large- tency, but require more storage, loose time synchroniza- scale distributed systems assume an underlying PKI—but tion, and complex key-pair pre-distribution. neglect to consider its performance impact. Understand- Subramanian et al. [36] proposed the Listen and Whis- ing the impact of the underlying PKI systems is a chal- per protocols to address the BGP security problem. The lenging task. In the future, we plan to analyze broader Listen protocol helps data forwarding by detecting “in- issues of PKI design and deployment that satisfy the se- complete” TCP connection; the Whisper protocol uncov- curity and performance requirements by these large-scale ers invalid route announcements by detecting inconsis- distributed systems and applications. tency among multiple update messages originating from In ongoing work, we are also exploring new path au- a common AS. The Listen and Whisper approach dis- thentication protocols that further improve performance. penses with the requirement of PKI or a trusted central- ized database, and aims for “significantly improved secu- rity” rather than “perfect security.” Acknowledgments [12] R. Housley, W. Polk, W. Ford, and D. Solo. Internet X.509 Public Key Infrastructure Certificate and CRL Pro- The authors are grateful to Patrick McDaniel, Kevin But- file. RFC3280, http://www.ietf.org/rfc3280.txt, ler, William Aiello, Steve Kent, Scot Rea, B. J. Premore, April 2002. and Hongsuda Tangmunarunkit for their valuable sugges- [13] Yih-Chun Hu, Adrian Perrig, and Marvin Sirbu. SPV: Se- tions. This research has been supported in part by Sun, cure Path Vector Routing for Securing BGP. In Proceed- Cisco, the Mellon Foundation, NSF (CCR-0209144, EIA- ings of SIGCOMM 2004, pages 179–192. ACM Press, Au- 9802068), AT&T/Internet2 and the Office for Domestic gust 2004. Preparedness, Department of Homeland Security (2000- [14] IANA: Internet Assigned Numbers Authority. http:// DT-CX-K001). This paper does not necessarily reflect the www.iana.org. views of the sponsors. [15] Internet corporation for assigned names and numbers. http://www.icann.org. References [16] Stephen Kent, Charles Lynn, Joanne Mikkelson, and Karen Seo. Secure Border Gateway Protocol (S-BGP) – Real [1] William Aiello, John Ioannidis, and Patrick McDaniel. World Performance and Deployment Issues. In The 7th Origin Authentication in Interdomain Routing. In Pro- Annual Network and Distributed System Security Sympo- ceedings of the 10th ACM Conference on Computer and sium (NDSS’00), San Diego, California, February 2000. Communications Security, pages 165–178. ACM Press, [17] Stephen Kent, Charles Lynn, and Karen Seo. Secure Bor- October 2003. der Gateway Protocol. IEEE Journal of Selected Areas in [2] Dan Boneh, Craig Gentry, Ben Lynn, and Hovav Shacham. Communications, 18(4):582–592, April 2000. A Survey of Two Signature Aggregation Techniques. RSA [18] Steve Kent. Securing the Border Gateway Protocol: A Sta- CryptoBytes, 6(2):1–10, 2003. tus Update. In Seventh IFIP TC-6 TC-11 Conference on [3] Dan Boneh, Craig Gentry, Ben Lynn, and Hovav Shacham. Communications and Multimedia Security, October 2003. Aggregate and Verifiably Encrypted Signatures from Bilin- ear Maps. In Proceedings of Eurocrypt 2003, number 2656 [19] Craig Labovitz, Abha Ahuja, Abhijit Bose, and Farnam in LNCS, pages 416–432. Springer-Verlag, 2003. Jahanian. Delayed Internet Routing Convergence. In Proceedings of SIGCOMM 2000, pages 175–187, August [4] CIDR BGP Reports from AS1221 (Telstra), October 2004. 2000. http://www.cidr-report.org/as1221/. [20] Craig Labovitz, Abha Ahuja, and Farnam Jahanian. Exper- [5] James Cowie, David Nicol, and Andy Ogielski. Model- imental Study of Internet Stability and Wide-Area Back- ing the Global Internet. IEEE Computing in Science and bone Failures. In Proceedings of the International Sympo- Engineering, 1(1):42–50, Jan.–Feb. 1999. sium on Fault-Tolerant Computing, June 1999. [6] Michalis Faloutsos, Petrof Faloutsos, and Christos Falout- [21] Craig Labovitz, Abha Ahuja, Roger Wattenhofer, and sos. On Power-Law Relationships of the Internet Topol- Srinivasan Venkatachary. The Impact of Internet Policy ogy. In Proceedings of ACM SIGCOMM’99, pages 251– and Topology on Delayed Routing Convergence. In Pro- 262. ACM Press, 1999. ceedings of INFOCOM 2001, pages 537–546, April 2001. [7] Lixin Gao. On Inferring Autonomous System Relation- ships in the Internet. IEEE/ACM Transactions on Network- [22] Anna Lysyanskaya, Silvio Micali, Leonid Reyzin, and Ho- ing (TON), 9(6):733–745, December 2001. vav Shacham. Sequential Aggregate Signatures from Trap- door Permutations. In Eurocrypt 2004, volume 3027 of [8] Goeffrey Goodell, William Aiello, Timothy Griffin, John LNCS, pages 74–90. Springer-Verlag, 2004. Ioannidis, Patrick McDaniel, and Aviel Rubin. Working around BGP: An Incremental Approach to Improving Se- [23] Zhuoqing Morley Mao, Ramesh Govindan, George Vargh- curity and Accuracy in Interdomain Routing. In The 10th ese, and Randy H. Katz. Route Flap Damping Exacer- Annual Network and Distributed System Security Sympo- bates Internet Routing Convergence. In Proceedings of sium, San Diego, California, February 2003. SIGCOMM 2002, August 2002. [9] Michael Goodrich. Efficient and Secure Network Routing [24] R. Merkle. Protocols for Public Key Cryptosystems. In Algorithms. provisional patent filing, http://www.cs. Proc 1980 Symposium on Security and Privacy, IEEE jhu.edu/∼goodrich/cgc/pubs/rout-ing.pdf, Jan- Computer Society, pages 122–133, April 1980. uary 2001. [25] R. Merkle. A Certified Digital Signature. In G. Brassard, [10] Ramesh Govindan and Anoop Reddy. An Analysis of In- editor, Advances in Cryptology – CRYPTO ’89, volume ternet Inter-Domain Topology and Route Stability. In Pro- 435 of Lecture Notes in Computer Science, pages 218–238. ceedings of INFOCOM 1997, pages 850–857, April 1997. Springer-Verlag, 1990. [11] Timothy G. Griffin and Gordon Wilfong. An Analysis [26] S. Murphy. BGP Security Vulnerabilities Analysis. of BGP Convergence Properties. In Proceedings of SIG- Internet-Draft, draft-murphy-bgp-vuln-00.txt, NAI Labs, COMM 1999, pages 277–288, August 1999. February 2002. [27] David M. Nicol, Sean W. Smith, and Meiyuan Zhao. Eval- [42] K. Zhang. Efficient Protocols for Signing Routing Mes- uation of Efficient Security for BGP Route Announce- sages. In The 5th Annual Network and Distributed Sys- ments using Parallel Simulation. Simulation Practice and tems Security Symposium (NDSS’98), San Diego, Califor- Theory Journal, special issue on Modeling and Simulation nia, March 1998. of Distributed Systems and Networks, 12(3–4):187–216, July 2004. [28] Andy T. Ogielski and James H. Cowie. SSFNet: Scal- able Simulation Framework - Network Models. http: //www.ssfnet.org. See http://www.ssfnet.org/ publications.html for links to related publications. [29] OpenSSL: The Open Source toolkit for SSL/TLS. http: //www.openssl.org. [30] Dan Pei, Xiaoliang Zhao, Lan Wang, Dan Massey, Allison Mankin, S. Felix Wu, and Lixia Zhang. Improving BGP Convergence through Consistency Assertions. In Proceed- ings of INFOCOM 2002, June 2002. [31] Brian Premore. An Analysis of Convergence Properties of the Border Gateway Protocol Using Discrete Event Simu- lation. PhD thesis, Dartmouth College, June 2003. [32] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP- 4). RFC1771, http://www.ietf.org/rfc1771.txt, March 1995. [33] The Route Views Project. http://www.antc.uoregon. edu/route-views/. [34] Aman Shaikh, Anujan Varma, Lampros Kalampoukas, and Rohit Dube. Routing Stability in Congested Networks: Ex- perimentation and Analysis. In Proceedings of SIGCOMM 2000, pages 163–174, August 2000. [35] B. Smith and J.J. Garcia-Luna-Aceves. Efficient Secu- rity Mechanisms for the Border Gateway Routing Proto- col. Computer Communications (Elsevier), 21(3):203– 210, 1998. [36] Lakshminarayanan Subramanian, Volker Roth, Ion Stoica, Scott Shenker, and Randy H. Katz. Listen and Whisper: Security Mechanisms for BGP. In Proceedings of First Symposium on Networked Systems Design and Implemen- tation (NSDI 2004), March 2004. [37] MitreTek Systems. Certificate Arbitrator Module. http: //cam.mitretek.org/cam/. [38] Hongsuda Tangmunarunkit, Ramesh Govindan, Scott Shenker, and Deborah Estrin. The Impact of Routing Pol- icy on Internet Paths. In Proceedings of INFOCOM 2001, pages 736–742, April 2001. [39] Iljitsch van Beijnum. BGP: Building Reliable Networks with the Border Gateway Protocol. O’Reilly, 2002. [40] Tao Wan, Evangelos Kranakis, and P.C. van Oorschot. Pretty Secure BGP (psBGP). In The 12th Annual Network and Distributed System Security Symposium (NDSS’05), San Diego, California, February 2005. [41] Russ White. Architecture and Deployment Considera- tions for Secure Origin BGP (soBGP). IETF Internet Draft http://www.ietf.org/internet-drafts/ draft-white-sobgparchitecture-00.txt, May 2004. 4th Annual PKI R&D Workshop Pre-Proceedings a valid identity certificate. Component certificates Observations from the Deployment are issued to web servers and other devices. Code of a Large Scale PKI signing certificates are issued to specific entities Rebecca Nielsen within the DoD that approve mobile code. Booz Allen Hamilton Other DoD PKI core components include the internal directory servers and the Key Escrow Database 1 Background (KED). All private keys associated with encryption certificates are escrowed prior to the issuance of the The United States Department of Defense (DoD) has certificate. been investigating the use of public key technology to help meet its information assurance goals since The DoD PKI supports two interfaces for certificate 1997. The DoD implemented a pilot Public Key issuance, hardware and software. Hardware Infrastructure (PKI) in 1998, and began a mass certificates are issued on the CACs to all DoD rollout of the current DoD PKI in 2000. Since then, personnel. The CAC is a Java smart card that has the DoD has successfully issued digital certificates on been validated against Federal Information Common Access Cards (CAC) to over 85% of its 3.5 Processing Standard (FIPS) 401 Level 2 million user population. While the deployment of the requirements. The Java card was selected both to DoD PKI has not always been smooth, the issuance allow for the inclusion of additional functionality of digital certificates has been one of the first truly beyond PKI on the card and to enable multiple enterprise-wide standard technology implementations vendors to provide card stock to the DoD. Identity within the DoD. proofing and certificate issuance on the CAC take place using the DoD’ s existing personnel This paper provides insight into some of the identification card issuance system. Since the CAs technology and organizational lessons learned in do not have a direct method for interfacing with the deploying the world’ s largest PKI from the CAC, issuance portals are used to facilitate key perspective of a DoD contractor. generation, certificate request generation, and insertion of issued certificates. 2 Managing the “I” in PKI Software certificates can be issued to people and web servers. Although the CAC is the primary issuance 2.1 The DoD PKI Architecture process for personnel, software certificates are used The DoD PKI consists of a to support some legacy single Root Certification applications that do not yet Authority (CA) and multiple support hardware tokens, subordinate CAs. The Root and in some environments CA only issues subordinate where CAC issuance is CA certificates. difficult. Software Subordinate CAs issue five certificates are requested via types of certificates: a Hyper Text Transfer identity, signature, Protocol, Secure (HTTPS) encryption, component, and interface and verified by code signing. Identity and Registration Authorities signature certificates can be (RA) and Local Registration used to authenticate to Authorities (LRA). applications or digitally sign For publication of PKI forms or email messages. information, the DoD PKI Because many DoD email interfaces with the Global addresses change when Directory Service (GDS). individuals move from one GDS is an internal location to another, the DoD enterprise directory that issues the primary identity supports both HTTPS and certificate with no email address. The signature and Lightweight Directory Access Protocol (LDAP) encryption certificates contain email addresses to interfaces. Subordinate CA certificates, Certificate support Secure/Multipurpose Internet Mail Revocation Lists (CRL), and encryption certificates Extensions (S/MIME) version 2 and 3. New email are published to the GDS from the DoD PKI. certificates can be issued based on the presentation of Subordinate CA certificates and CRLs are also 155 4th Annual PKI R&D Workshop Pre-Proceedings published to an external X.500 directory for access Although the GDS is the primary interface for outside of the DoD. applications to retrieve CRLs and for end users to search for encryption certificates, direct searches of Certificate revocation is performed by RAs using an the CA internal databases are still required, primarily HTTPS interface. Key recovery is performed by key for certificate revocation. When requesting recovery agents who access the KED using an certificate revocation, most users and supervisors do HTTPS interface. not know the CA and serial number for the certificate that needs to be revoked. As a result, the RA must 2.2 Certification Authority (CA) Scalability search multiple CAs to locate the correct certificate prior to authorizing its revocation. Take into account all of the required tasks when developing architecture requirements. 2.3 Hardware and Software Maintenance When designing the infrastructure, the DoD performed load testing to determine how many PKI cycle times are significantly different certificates a given CA could issue. However, this then hardware and software cycle times. initial load testing did not account for the many other functions that CAs must be able to perform at the 2.3.1 CA Hardware and Software same time as certificate issuance, including the The DoD PKI was designed for the long term. The following: DoD Root CA has a validity period of thirty-six • validating credentials of trusted personnel, years. Each subordinate CA has a validity period of six years. Subordinate CAs issue certificates for the • publishing certificates, first three years of their validity period and are then • generating CRLs, “ retired” so that they only issue CRLs for the • publishing CRLs, remaining three years. CAs are only taken • revoking certificates, completely out of service once all certificates issued by the CA have expired. CACs issued to • responding to requests to search for specific Government personnel are valid for three years, certificates. while those issued to contractors are valid for up to The DoD PKI has over 2,000 approved RAs. one year. Because of personnel turnover, the list of approved In contrast, hardware life cycles are one to three RAs changes frequently. To ensure that certificates years, and software product cycles can be eighteen can still be issued if one or more CAs are months or less. As a result, neither the software nor unavailable, the DoD PKI is configured so that all the hardware in use for the DoD Root CA are still RAs are authorized on all CAs. The interface supported by their respective vendors. Older provided by the vendor to manage trusted personnel subordinate CAs are also operating on non-supported did not support the large number of RAs or the versions of hardware and software, increasing both requirement for frequent updates. To minimize the the requirement for and the cost of maintenance. impact to CAs, the DoD has developed custom scripts that allow changes in RA personnel to be 2.3.2 Key Length quickly uploaded to all CAs. In addition to product life cycles, the basic The process of generating CRLs requires significant technology behind PKI is also changing. When the CA processing time, both in determining which Root CA was established, 512-bit keys were still in certificates have been revoked, and, as the CA ages, use, and 1024-bit keys were the longest supported by determining which revoked certificates have expired vendors. Today, 1024-bit keys are standard, and the and should not be placed on subsequent CRLs. For Federal Government has published guidelines that all CAs that issue a large number of certificates, the certificates that will expire later than 2008 should be requirement to check each revoked certificate for its issued with 2048-bit keys. expiration date can cause the total time to generate a CRL to be greater than the next update period of the As a result, the DoD PKI is currently working on a CRL. While CRL generation requires less processing solution to upgrade the Root CA. There are two time if expiration date checks are not performed, options for upgrading, migrating the current Root CA continuing to include expired certificates on CRLs to newer hardware and software versions, or increases the overall CRL size. establishing a new Root CA and issuing a rollover certificate from the current Root CA to the new Root CA. Migrating the existing Root CA is simpler for 156 4th Annual PKI R&D Workshop Pre-Proceedings the short term, but does not solve the problem of the the 32k chip currently supported. This new chip will 1024-bit Root CA signing key length. support additional capabilities beyond PKI. The additional space may also support better security Establishing a new Root CA with a 2048-bit signing protections, which would enable users to perform key will require pushing down the new key to all more card maintenance, such as certificate update, applications relying on certificates from the DoD from their own workstations instead of having to PKI. In addition, a new Root CA will require return to an issuance station. However, all DoD users maintaining two infrastructures for three to six years, will not be able to take advantage of these new depending on whether all current subordinate CAs capabilities until all cards have been replaced through are retired when the new Root CA is established. normal expiration. 2.3.3 Certificate Profile 2.4 Personnel Another issue with the long term nature of the PKI is that changes to certificate profiles require over three Integrating PKI rollout with existing years to implement. For example, the DoD PKI processes is a requirement for success. initially did not support the extensions required to use digital certificates to authenticate to Microsoft The initial DoD PKI rollout was planned as a Windows-based networks. Windows requires the software-based implementation. The DoD would following extensions in certificates1: centrally manage the PKI core components, and each DoD service or agency would provide personnel to • CRL Distribution Point must be present, act as RAs and LRAs who would register individuals. • Key Usage must be set to Digital Signature, When early adopter applications tried to get their • Extended Key Usage (EKU) must contain the users registered to get certificates, however, they Smart Card Logon Object Identifier (note that if found that RAs and LRAs were not available. Local the EKU extension is populated, it must also commands resisted the requirement for additional contain the identifiers for all other uses for the personnel, and the travel costs for sending RAs and certificates, such as Client Authentication), LRAs to training. • Subject Alternative Name must contain a User At the same time the PKI was performing initial Principal Name (UPN) of the format rollout, the personnel office was developing a new user@name.com. identification (ID) card to be rolled out to all DoD Once the requirements were determined and the military and civilian employees. In November 1999, changes implemented at the subordinate CAs, all new the DoD made a decision to combine the two CACs contained a signature certificate with the programs and use the new ID card as a hardware additional information. However, there are still token for digital certificates. As a result of this some subscribers within the DoD that do not have the decision, the PKI and personnel offices worked required extensions on their CACs. together to design a process that used existing ID card issuance stations to verify identity and issue Another example is the Authority Information Access certificates in conjunction with ID cards. extension. Research by the Federal Bridge Path Discovery and Validation Working Group has This new process did increase the personnel indicated that path discovery is facilitated when requirements for ID card issuance stations. Prior to certificates contain the Authority Information Access the CAC, DoD ID cards were only issued to military (AIA) extension2. The DoD PKI does not currently personnel, but CACs are issued to military personnel, include the AIA extension. If the DoD makes a civilian employees, and on-site contractors. Also, the decision to modify its certificate profiles to include time to issue CACs is longer then the time to issue the AIA extension, the change will take three years to the old ID cards. However, combining certificate be reflected in all DoD PKI issued certificates. issuance with ID card issuance allowed the PKI to take advantage of the existing ID card infrastructure 2.3.4 Smart Card Technology and minimized the personnel requirements for services and agencies. Also, the requirement for In addition to CA and certificate profile updates, the personnel to get a new ID card facilitated the DoD must manage user smart card migration issues. issuance of certificates. Since most CACs are valid for three years, CAC middleware must concurrently support three years of smart card technology. The DoD is investigating upgrading new card stock to a 64k chip, instead of 157 4th Annual PKI R&D Workshop Pre-Proceedings 3 Technology Challenges The DoD PKI has examined two alternate CRL approaches, partitioned CRLs and delta CRLs. A CA Building the capability to support the DoD enterprise creating partitioned CRLs divides certificates into is not sufficient for the success of the DoD PKI. blocks of a preset size based on information Since PKI is an infrastructure technology, it does not contained in the certificate such as the certificate solve any operational requirements unless public key serial number. Instead of issuing one CRL, the CA technology is integrated into applications. This issues multiple CRLs, one for each preset block of section explores the two most significant challenges certificates. When an application attempts to validate that the DoD PKI has experienced in gaining a certificate, it checks to see if a current CRL for the acceptance from the functional community for the block the certificate is contained in is locally cached, use of PKI. and downloads the CRL partition if it is not. While partitioned CRLs allow applications to only retrieve 3.1 Certificate Status Checking limited CRL information, the DoD has not developed a solution involving partitioned CRLs, partially Checking certificate revocation status is the because of the lack of support from either CA or most difficult technical challenge of PKI. application vendors. CRLs are theoretically elegant. They provide a A CA supporting delta CRLs issues a full CRL once mechanism for a CA to state that it no longer asserts or periodically, and then only issues delta CRLs that the binding between the identity in the certificate and contain certificates that have been revoked since the the associated key pair for a set of certificates that it last delta CRL was issued. As a result, delta CRLs issued. CRLs provide only a minimum set of data, are significantly smaller than full CRLs. However, the certificate serial number, the date of revocation, applications must have a mechanism of ensuring that and optionally a reason for revocation. Because they they have downloaded all delta CRLs, because no are digitally signed, the transmission mechanism does single CRL can be considered an authoritative source not itself have to be trusted in order to accept the for information on the revocation status of any given information contained in the CRL. certificate. Although the DoD PKI does not support In practice, however, relying on CRLs has not delta CRLs, one agency within the DoD has worked well. Products that are enabled to use digital successfully piloted a delta CRL approach for certificates only provide minimal support for CRLs. transmitting revocation information in a severely In some cases, no provision is provided to automate bandwidth constrained environment. the downloading of CRLs. Vendors who do provide In general, CRLs have been an effective method of an automated update capability may not allow setting transmitting revocation information across enterprise when the attempt to retrieve a new CRL occurs, networks with high bandwidth availability, but are which can result in multiple applications attempting too cumbersome to use to get this information down to access the CRL repository at the same time. At to individual applications. least one vendor treats the next update field of a CRL as an expiration date, and will not validate any As a result of the continued issues with performing certificate issued by a CA for which a current CRL is certificate validation using CRLs, the DoD PKI is not available. Finally, the information contained in a deploying an infrastructure to support revocation CRL is only as current as the time the CRL was status checking using the On-line Certificate Status published, which results in significant latency issues. Protocol (OCSP). To meet the requirements for decentralization, availability, and scalability, this The scale of the DoD PKI results in an additional infrastructure will not interface directly with the DoD problem, the overall size of CRLs. The combined PKI CAs. Instead, it will provide a capability to size of the CRLs from all of the DoD PKI CAs is download CRLs and provide real-time OCSP approaching 40 megabytes. It is not feasible for responses from multiple locations across the DoD every application on DoD networks to download this network. Instead of downloading CRLs, applications amount of data every day without having a that support OCSP will able to get real-time significant impact on available bandwidth. responses for specific certificates from this global Although CRLs are an efficient way of publishing robust certificate validation system. Although the revocation information for the entire PKI, no single use of CRLs as the authoritative source for application has all subscribers as users, so each revocation information does not address the latency application only needs a subset of the information. issues of CRLs, this hybrid approach of CRLs and However, the enterprise PKI does not know in OCSP will take advantage of the efficiency of CRLs advance which subset is needed by each application. 158 4th Annual PKI R&D Workshop Pre-Proceedings and provide an interface for applications that is easier 4.1 The Users to implement and maintain. Provide users with new capabilities that help 3.2 Key Recovery them to get their jobs done, not just PKI certificates. The person most likely to need key recovery capability is the subscriber. Most users will embrace new technology if they see a clear benefit to its use. However, PKI was initially The DoD PKI key escrow and recovery solution was marketed as a technology, not as a mechanism for designed when the DoD PKI was primarily issuing getting the job done. For example, “ PKI 101” software certificates. The solution was designed to training often starts by stating the concepts of public support situations when a private key needed to be key technology, then introduces the user to “ Alice” recovered by a manager or law enforcement agent to and “ Bob” who are exchanging signed and encrypted access encrypted data, and occasionally by email messages. By this time, attendees have subscribers who had lost their private keys. As a decided that PKI is very complicated and since they result, the process was manual and personnel can send email without PKI (and have been doing it intensive, requiring first that requestors verify their for years without problems), they leave the training own identities and provide justification for the having decided that PKI is too difficult. request, and then that two key recovery agents The DoD PKI was originally targeted as a pilot that together retrieve the escrowed keys out of storage. would provide better assurance for a new electronic The transition to the CAC as the token for key travel system. Through the use of digital signatures, generation and storage created a significant change in travel claims could be processed significantly faster, the key recovery requirement. Since the private key resulting in shorter times for employee associated with each subscriber’ s encryption reimbursements. Once deployed, the PKI could then certificate is stored only on the CAC, subscribers lose be used with other systems. However, delays in the access to their own private keys at CAC expiration rollout of the travel system and the decision to because the old CAC is surrendered at the time of implement a smart card-based PKI meant that many new CAC issuance. In order to access files users were issued a CAC months prior to receiving a previously encrypted, all subscribers must recover smart card reader and without any application their old private keys. requiring use of their new certificates. As a result, most users’ experience with PKI consisted of waiting The manual process which was designed to prevent in line to get a CAC and then using the CAC the abuse of key recovery is too costly to support for a same way they had used the ID card they had prior to large number of individuals requesting their own the CAC. These users did not see any real benefit to escrowed private keys. Since individuals are the new technology. assumed to be authorized to have access to their own keys, a more automated process is being developed Although smart card readers are being deployed and that will allow subscribers to use their identity applications are beginning to incorporate support for certificate to authenticate to the key escrow system public key technology, the DoD PKI continues to and request retrieval of their own private keys. struggle to attain widespread user acceptance. 4.2 The Managers 4 Organizational Challenges Although the implementation of the DoD PKI has Application owners need policy, budget experienced technical challenges, overcoming guidance, and a business justification for organizational obstacles has sometimes proved a adopting public key technology. harder task. Some of these obstacles are independent of PKI, such as issues relating to coordinating Within the DoD, funding for PKI core components common processes across the worldwide enterprise, and card stock is centrally managed. However, developing working relationships between disparate individual applications, including email, networks, commands within the enterprise, and determining and web servers, are very decentralized. Therefore, which organizations within the enterprise should rolling out the PKI required a few decisions by policy have primary responsibility for each element of the makers, but integrating public key technology into overall architecture. This section highlights some of applications requires many decisions by many the organizational challenges specific to PKI application owners. These managers must consider implementation for users, managers, and developers. 159 4th Annual PKI R&D Workshop Pre-Proceedings multiple demands when determining how to allocate capabilities, replacing components with similar limited resources: components from different vendors that support required capabilities, and building interfaces between Getting support from application managers requires enabled components and those that do not support providing managers with the information they need to public key technology. make decisions including the following: Unfortunately, there are relatively few individuals • Ensure that published policy is consistent with the who understand both PKI and application organization’ s goals for integrating public key architectures. Available PKI training consists technology. Policy enables early adopters of new primarily of lessons on how to stand up the technology to justify their investments. infrastructure; it does not focus on how to integrate • Provide direction for requesting funding for public PKI into existing applications. Vendors provide key enabling as a part of the standard budget cycle. some guidance, but this information is usually limited Getting out of cycle funding to meet security to the vendor’ s own products. driven requirements is difficult and almost always means that other planned functionality must be For example, a web server vendor will provide sacrificed to meet PKI requirements. instructions on how to request and install a server certificate and how to turn on client certificate-based • Use specific examples when presenting security authentication. The vendor may also provide requirements to application owners to show what instructions on how to perform certificate validation. vulnerabilities exist in current systems and how However, nothing is provided on how to integrate the the use of PKI can help to mitigate them. authenticated identity information from the certificate • Define business case benefits for PKI in addition with access control to a database or other back end to the “ better security” case. Because PKI component. acceptance has been primarily in the security community, explanations for why to integrate Training targeted at developers on how to integrate public key technology tend to be heavily security PKI into real-world applications should become focused. The business case for PKI, including much more widely available. more efficient user management, decreased password management, and new functionality 5 Conclusion capabilities, should be more clearly stated. As the DoD has rolled out PKI, it has experienced Getting the acceptance of application owners is a technical challenges. However, PKI has been more critical step in showing a return on investment in successful than many technologies in meeting the PKI. However, most application owners will not scalability demands of the DoD enterprise. By commit to enabling existing applications until the integrating certificate issuance with existing users have digital certificates. DoD applications that personnel processes, the DoD PKI has been able to made initial investments in using PKI in the late perform in-person identity verification to over three 1990s all delayed public key enabling because of the million users. Technology challenges have been met inability of their internal DoD users to register for using a combination of redundant systems and certificates. Now that the DoD has invested customized interfaces developed by DoD, contractor, resources to issue certificates to eligible users, these and vendor personnel working together. The only and other applications are finally beginning the basic building block of PKI that has not scaled transition to using public key technology. successfully is the CRL. However, the DoD is working to overcome this barrier through the use of 4.3 The Developers OCSP. Better training is needed to assist developers The DoD PKI rollout has also encountered issues in public key enabling. surrounding the enterprise nature of PKI. PKI implementation has required that existing business Ultimately, the success of PKI is dependent on process problems be resolved prior to the success of developers performing system integration to public PKI. key enable applications. DoD applications usually The more difficult challenges have been in getting involve some components, such as web servers, that acceptance from the user, application owner, and have native support for some PKI capabilities and developer communities. A primary reason for this other components that do not support PKI. Public issue is the lack of good training available targeted key enabling, therefore, can require upgrading specifically to the interests of these communities. software to later versions that support required 160 4th Annual PKI R&D Workshop Pre-Proceedings The DoD is committed to continuing down the path of PKI deployment and public key enabling of applications. The implementation of PKI is a long term investment, since application owners do not want to commit to using certificates until they believe that their user population has the capability to get certificates. Unfortunately, the return on investment in PKI does not become measurable until applications have started to use the technology. Staying the course has presented challenges, but the potential of public key technology, both in current architectures and in the next generation Net-Centric environment, is critical to meeting the DoD’ s information assurance goals and improving its business processes. 1 “ Guidelines for Enabling Smart Card Logon with Third-Party Certification Authorities,” Microsoft Knowledge Base Article 281245. http://support.microsoft.com/default.aspx?scid=kb;en -us;281245 2 “ Functional Requirements for Path Validation Systems,” Path Validation Working Group, Draft Version 0.8, March 2004. http://www.cio.gov/fbca/pdvalwg.htm 161 Language based Policy Analysis in a SPKI Trust Management System Arun K. Eamani and A. Prasad Sistlax University of Illinois at Chicago {aeamani, sistla}@cs.uic.edu Abstract— SPKI/SDSI is a standard for issuing autho- logic, for example retrieve all the principals who were rization and name certificates. SPKI/SDSI can be used able to access a resource R at some point in a time to implement a Trust Management System, where the interval. policy for resource access is distributively specified by multiple trusted entities. Agents in the system need a There have been a string rewriting system [CEE+ 01] formal mechanism for understanding the current state of policy. We present a first order temporal logic, called FTPL and a push down system(PDS) [JR01] to model for specifying properties of a given SPKI/SDSI policy state. certificate analysis problems in a SPKI/SDSI framework. We also present algorithms to check if a SPKI/SDSI policy We propose that temporal logic be used as a language to state satisfies a property specified in FTPL. specify the issues of authorization, naming and validity. The policy analysis problem would be specified as a temporal logic formula f and we evaluate the formula I. I NTRODUCTION on a given set of certificates C and a particular time A. Motivation and Use of the Language instance t. The formulas of the logic could be interpreted not only to evaluate the truthness of a statement but also SPKI/SDSI (simple public key infrastructure/simple to reason about the state of the system by finding all distributed security infrastructure) is a mechanism instantiations of free variables which would make the for specifying policy in a distributed access control formula true in the given state of system at a particular system [EFL+ 99], [Ell99]. With standardized semantics instant of time. it can also be viewed as a Trust Management Language [BFK99]. There has been much work done In access control models the usual analysis consists on analyzing fixed a priori defined properties of such of safety analysis [HRU75]: does there exist a reachable an authorization system [JR01], [CEE+ 01]. In this state where a untrusted principal has access to the paper we introduce a language based on general resource? A state in the system corresponds to a set purpose temporal logic for specifying properties of of signed policy statements i.e certificates. We change such a system. This language, called FTPL: First the policy state by adding or deleting a certificate. order Temporal Policy analysis Logic, could be used Li et al [LWM03] propose security analysis where by the agents to reason about the state of the policy. the state can change in a restricted manner. Security Such analysis is useful for understanding the current analysis is a study of security properties such as safety, state of policy, auditing the past policy statements, to availability, containment etc. Availability requires that point out any violations in trust between agents and in every reachable state a particular principal will be for aiding policy refinement/management. We present able to access a resource. Containment requires that efficient methods for automatically checking if a given in every reachable state if a particular principal has a SPKI/SDSI certificate set satisfies a policy question property, say being able to access a resource, then that specified in the logic. The logic that we use is an principal also satisfies a condition, like being member extension of the standard real-time temporal logic of a particular role. The above type of analysis is useful extended with quantifiers over the principals in the to understand how the current policy state can evolve. system. Many important properties such as the following can be expressed in our logic - can two principals K1 We propose policy analysis in distributed access and K2 access the resource R simultaneously at some control models, where we analyze properties of a point in future? We can also specify queries in this particular policy state. We consider a policy state as x This research is partially supported by the NSF Grants CCR- consisting of a set of policy statements each labeled with 0205365and CCR-9988884 a validity interval. Each policy statement is valid during the time interval associated with it. At any point of time The logic we propose would provide the resource only a subset of the given set of certificates are valid. administrator with a formal and a high level mechanism Policy analysis can also be viewed as a special case of for specifying policy properties. The language could security analysis where all the possible state transitions also be useful for the other types of users, like a are know in advance, given that certificate issuers client to reason about properties such as “is there an specify the time period during which the certificate authorization chain leading to the client from a particular is valid. We can reformulate the problems of security principal?” etc. analysis to reason over time instead of reachable states. For example the availability property could be restated The paper will consist of five other sections, section as: at all times in future does a principal K have access [2] presents short description of related work. Section to a resource R. While, for practical reasons, we may [3] consists of introduction to SPKI/SDSI and previous want to reason about bounded availability: at all times models for certificate analysis problems. Section [4] will during a time interval, say a school semester is a student consist of our proposed logic and examples of policy K able to access the school ftp server R. problems specifiable by the language and section [5] will contain algorithms to evaluate the formulas of the logic. In a SPKI/SDSI system, given certificates containing Section [6] consists of conclusion and future work. validity intervals, authorization and name relationships vary with time. In a delegation based system where II. R ELATED W ORK multiple agents make policy statements regarding access There are other logics for SPKI/SDSI which model of a particular resource, no agent is aware of the overall the name resolution, authorization and other features of state of the policy. There being a large number of policy SPKI/SDSI: Martin Abadi’s logic to model local name statements, manual analysis is not an option. Many spaces of SDSI [Aba97], Halpern and van der Meyden’s policy specification languages including SPKI/SDSI Logic of Local Name Containment to characterize cannot specify constraints such as negative credentials, SDSI name resolution which was extended to deal with mutual exclusion, etc. necessitating a mechanism to other SPKI issues like revocation, expiry dates, and make sure that agents didn’t make policy statements tuple reduction [HvdM01]. Ninghui Li [Li00] proposes which violate the unspecifiable constraints. In addition, a logic program to describe the name resolution analysis of current policy state is useful to formally algorithm which also handles authorization certificates reason whether the current policy state satisfies user and threshold subjects. The purpose of our logic is defined properties and to gain knowledge for making neither to model the features of SPKI/SDSI nor to decisions about changing the current policy state. Based provide for its semantics but for policy analysis. Jha on current policy state, we can also reason about issues and Reps [JR01] propose using temporal logic to reason of authorization and naming in future time. about certificate chain derivations in a given SPKI system, while we propose using temporal logic as a We also propose policy audit, where we check for language for specifying certificate set analysis problems policy violations over a set of all the policy statements involving authorization, naming and validity. which were valid during the time of audit. In access control audit, the problem is of type: did principal K There have been many languages, logic and semantic access a resource R?, while in policy audit we check frameworks to express authorization policy in a whether a principal K had permissions to access a distributed system. Datalog and its variants seem to resource R? or whether principal K1 gave authorization be the language of choice to specify authorization regarding a resource R to principal K2 . Policy audit policy [LM03]. A specific class of distributed access is a means to ascertain whether trusted agents were control systems attracting much attention are the Trust really trustworthy with regards to policy specification. Management Systems [BFK99], [BFIK99]. The concept By suitably shifting the timeline, we can use FTPL for of Trust Management is that there exists a standard purpose of reasoning about current policy state as well mechanism for expressing the access control policy as for policy audit. For purposes of policy audit, we and also a standard method to verify that an access collect the set of all policy statements corresponding to request complies with the policy. This is called “Proof the time of audit and evaluate the formulas of the logic of Compliance”. SPKI/SDSI was not intended by the over the static collection of policy statements labeled authors to be a Trust Management System in that Proof with validity periods. of Compliance can be application dependent, but it can be viewed as a Trust Management System with standardized certificate chain reduction rules [EFL+ 99]. trusted to issue certificates bearing their signature. Though lot of work has been done in specifying policy and checking whether an access request is compliant In SPKI/SDSI resource owners can delegate access with the policy in a distributed access control system, rights to trusted entities and they can issue certificates not much literature exists regarding a language based authorizing others, leading to a chain of certificates from mechanism for detailed analysis of policy beyond simple the resource owner to the end user. In a SPKI/SDSI authorization problems. To our knowledge FTPL is the system principals and resources are identified by their first such language for high level policy analysis in not corresponding public keys. We can still associate names just a SPKI/SDSI system, but in the distributed access with the principals. Every principal has a local name control framework. While we give a logic to formulate space and the principal is free to define local names in policy analysis problems in the context of SPKI/SDSI his domain independent of others. For example for a we feel that full fledged languages for policy analysis UIC student John, university may be defined as KU IC , in other distributed access control systems and trust while for a UIUC student Jim, university may be defined management systems are of much use to the users of as KU IU C . KU IC , KU IU C are the public keys of the the system. universities UIC and UIUC respectively. Public keys being unique throughout the system, a name qualified We give a list of specifiable problems that could by the public key of the principal defining the name, is be of interest in SPKI/SDSI policy analysis including also unique. some given by Jha and Reps [JR01]. The problems they Definition 1: An identifier is a word over a given list can be qualified by time. For example Authorized alphabet. The set of identifiers is denoted by I . The set Access 1:“Given resource R and principal K , is K of keys is denoted by K. authorized to access R?”, can be more specifically Definition 2: A local name is a sequence consisting written in the context of time as:“Given Resource of a key followed by a single identifier. A local name K R and principal K is K authorized to access R at friend may be defined as Kbob , Kj im ,... etc a particular instant of time, or at some point in a There is another kind of name in SPKI/SDSI called time interval?” While Jha and Reps provide a lattice extended name which increases the level of indirection based time structure which can be used to model such in the naming scheme. problems, we give a logic based formalism to specify Definition 3 : An extended name is a sequence con- such problems. sisting of a key followed by two or more identifiers. An example of an extended name is K brother friend, where the meaning of friend would be evaluated in the context III. SPKI/SDSI of K 0 s brother. Definition 3: A Name is either a local name or an A. Introduction extended name. We denote the set of all names as N . SPKI and SDSI are certificate based mechanisms Definition 4: A Term is either a key or a name. We for authorization and naming in distributed systems use T = K + N to denote set of all terms. respectively. SPKI 1.0 : simple public key infrastructure, Definition 5: We define a fully qualified name also to was a mechanism for expressing authorizations and mean a public key or a local name or an extended name. delegations, where it was proposed that permissions be given directly to the public keys of entities. The most important contribution of SDSI: simple distributed B. Certificate Structure security infrastructure, was to create local namespaces There are two types of certificates or certs in distinguished by the unique public key of the entity SPKI/SDSI: name certs and authorization(auth) certs. defining the names, instead of trying to create a The function of a name cert is to define a local name as globalized namespace. Features of SPKI 1.0 and SDSI another term. Only the principal, in whose namespace 1.0 were integrated into SPKI/SDSI 2.0 [EFL+ 99]. the local name is defined, may issue the corresponding In the future if we say SPKI we mean SPKI/SDSI name certificate. In an auth cert a principal can grant or 2.0 unless mentioned otherwise. One of the features delegate permissions regarding accessing a resource to of the SPKI is that every principal is free to issue another term. We now describe the logical structure of certificates signed by himself unlike in X.509 PKI the SPKI/SDSI certificates. framework [ADT02] where there are separate set of There are four fields in a name certificate (K, A, S , V ) principals called certificate authorities(CA) who are which is signed with the private key of the issuer: K −1 . K is the public key whose namespace is being receives a set of certificates it verifies them for integrity considered, A is an identifier in I and S is an element and stores them in an unsigned form called the tuples. of T , i.e. it can be another public key, or a local name We use the terms certificates and tuples interchangeably or an extended name. S is the term implied by the as far as there is no confusion. local name KA . V is a validity specification which Consider a certificate issued by K1 to a key K2 with states the validity condition for the certificate. The basic authorization actions A1 and and validity specification validity specification is of form [t1 ; t2 ] where t1 ; t2 are V1 , suppose delegation bit D1 is also true. Then the absolute time constants. The certificate is said to be valid certificate is logically represented as 5-tuple from time t1 to t2 . If either t1 or t2 are not given we assume −∞ or +∞ respectively. Validity specification C1 : (K1 ; K2 ; D1 ; A1 ; V1 ) could also be a certificate revocation list or an online Given D1 to be true, let K2 delegate authorization check [CEE+ 01]. In our model of SPKI we consider a actions A2 to subject S2 , with validity condition V2 and validity specification to be a certain time period in the delegation bit D2 . interval 0 to ∞. The authorization certificates consist of five fields C2 : (K2 ; S2 ; D2 ; A2 ; V2 ): (K; S; D; E; V ) signed by the private key of the According to the tuple reduction rules the result of issuer: K −1 . The main purpose of an SPKI authorization composition of the certificates C1 and C2 in that order certificate is to grant or delegate a set of authorization is another certificate C 0 equivalent to the chain actions as specified by E to the subject S ∈ T . K is the public key of the certificate issuer. C1 ◦ C2 ≡ (K1 ; S2 ; D2 ; AI nter sect(A1 ; A2 ); S is the Subject which can be either a key or a name. D is the boolean delegation bit which controls the V I nter sect(V2 ; V2 )): delegation rights. These equivalent certificates can also be used as a regular E is the set of authorization rights which are granted certificates in the SPKI system and are called Certificate or delegated to the subject by the issuer. Note that au- Result Certificates (CRC). thorization actions have address of the resource encoded AI nter sect() is the intuitive intersection of authoriza- in them. In our logic when we say read we mean read tion action sets. Howell and Kotz [HK00] note that the of a particular resource R defined in the context. intersection may not always be well defined. For the pur- V is the Validity specification and the observations pose of our logic we consider authorization actions to be made above for name certs are applicable here also. simple constants. Date range intersection V I nter sect() Delegation bit D implies that when the bit is set to one is the intersection of corresponding validity intervals. then the subject can access and also delegate the rights specified by set E to other users in the system, if the bit D. Models for SPKI Certificate Analysis. is zero then the subject only gets the right to perform actions specified by E , but cannot further delegate these There are two primary models for tuple reduction rights to any other user. problems, one is the string rewriting model of Clarke et al [CEE+ 01] and the other is the push down sys- tem(PDS) based semantics of Jha and Reps [JR02]. We C. Tuple Reduction present the PDS based model of [JR02] In a delegation based distributed access control system 1) Push Down System based Semantics: Jha and the resource owner permits others to specify policy Reps [JR01] model tuple reduction problems as config- regarding the access of the resource. Entities entrusted uration reachability problems in a pushdown system. A with delegation rights further propagate the access rights. push down system is similar to a push down automata This leads to a chain of certificates for accessing a but without the input alphabet. They view the autho- resource. The principal requesting access would present rization problem: can a principal Kp access resource the resource administrator with a requested authorization a R as a configuration reachability problem in the action and a chain of certificates which should prove pushdown automata and use the PDS model checking that the requesting principal has the right to perform the algorithms [EHRS00], [BEO97] to answer the prob- requested action. Given a chain of certificates, one must lem. The configuration of a PDS contains information deduce authorization and validity information from the about the control state and stack state of the PDS at chain. The rules which specify the inference conditions a particular point in the computation. A configuration are called the tuple reduction rules. When an entity of PDS corresponds to a term in a SPKI system. If a configuration GT reaches another configuration GS The symbol ¤ implies permission to delegate while using the state transition rules, then the corresponding ¥ just grants access. The set ∆ of state transitions term T can resolve to term S , defining the “ term reach- contains a transition (K γ ,→ K 0 ω) for every cert rule ability semantics” for the SPKI/SDSI system. PDS State (K γ → K 0 ω). The term K1 A B corresponds to the transition rules correspond to the SPKI/SDSI certificates. PDS configuration hK1 , A Bi, term K corresponds to The PDS formalization is also more expressible then the hK, ²i. When the PDS is in configuration hK1 , A Bi rewriting system of Clarke et al [CEE+ 01] to formulate and there is a state transition rule(cert) K1 A ,→ K2 various certificate analysis problems. We now describe then it goes to configuration hK2 , Bi. The reachability the method to build a push down system from a given relation ⇒∗ defines set of all terms which a given set of certificates and then model the certificate analysis term can resolve to. For authorization derivability, the problems using configuration reachability relation of the PDS configuration is of the form hK, ¤i which means PDS. The primary issues of certificate analysis are that principal K can access and delegate permissions, or of of name resolution and authorization derivability. For the form hK, ¥i which means K can just access. A purposes of the algorithm we convert name certs of form principal K can access the resource R if there is a run (K, A, S, V ) into the rewriting rule KA → S , auth cert of the PDS from configuration hR, ¤i to either of the (K, S, d, E, V ) is written as rule K¤ → S¤ if d = 1 configurations hK, ¤i or hK, ¥i. Whether a term can else as K¤ → S¥ if d = 0. V and E are ignored for resolve into another term can be decided in the PDS now, we consider that each resource has only one type system in time O(n2 LC ) where n is the total number of of access right. keys in the certificate system C, and LC is the sum of A pushdown system is formally defined as a triple lengths of the right hand side(rhs) of all the certificates P = (Q, Γ, ∆), where Q is a finite set of state in the system. Length of the rhs of a cert is the number variables, Γ is a finite set of stack symbols, and of non-key symbols on the rhs of the rule corresponding ∆ ⊆ Q × Γ × Q × Γ∗ is the finite set of state to the cert. transition rules. If (q, γ, q 0 , w) ∈ ∆ then we write (q, γ) ,→ (q 0 , w). The PDS P when in state q and γ We use term reachability semantics of the PDS model on top of stack, uses the above transition rule to goto to define the FTPL semantics. For that purpose we mod- state q 0 , popping γ and writing string w onto the stack. ify the PDS described above by adding an authorization The ,→ corresponds to the rewriting relation between variable v to the system to form a augmented PDS various elements of a SPKI certificate. A configuration P = (Q, Γ, δ, v). The authorization rights a principal of P is a pair hq, wi where q ∈ Q and w ∈ Γ∗ . Here grants to another principal are computed as the side- q denotes the control state and string w the stack effects of the run of the PDS using the authorization state. The set of all configurations is denoted by G . variable v . At the start of a computation v is initialized Corresponding to the transition relation of the PDS to A, the set of all authorization rights for the resource states we have the (immediate) reachability relation being considered. Each auth cert rule is labeled with of the configurations. If (q, γ) ,→ (q 0 , w) then for all the authorization rights granted to the subject of the v ∈ Γ∗ , hq, γvi ⇒ hq 0 , wvi, i.e. configuration hq, γvi is cert. Accordingly, we also label the corresponding state said to be the immediate predecessor of hq 0 , wvi. The transition rule in δ . In the PDS P whenever we go from reflexive transitive closure and the transitive closure of one configuration to another configuration using a state the immediate reachability relationship(⇒) are denoted transition rule labeled with a set of authorization rights by ⇒∗ and ⇒+ respectively. A run of a P DS is E, we update the authorization variable v as v = v ∩ E . a sequence of configurations c0 , c1 , ...cn such that If the PDS goes from configuration hK1 , ¤i to hK2 , ¤i ci is an immediate predecessor of ci+1 . The run of with the value of v as A1 at the end of the run, then a PDS corresponds to a SPKI certificate chain reduction. K1 directly/indirectly delegates to K2 the authorization rights A1 . Given a set of certs C with principals(keys) represented by K and identifiers by I , we construct a IV. L OGIC FOR P OLICY A NALYSIS PDS PC (Q, Γ, ∆) as follows. The set of control states is the set of keys, Q = K. A. Definition of the Logic Note that we only analyze authorization problems We define a polyadic First order Temporal Policy concerning a particular resource which is identified by analysis Logic (FTPL) as a language for specifying prop- a special key R in K . The stack alphabet is set of erties of a SPKI/SDSI certificate system. The formulas of identifiers and the delegation symbols, Γ = I ∪ {¤, ¥}. the logic are to be evaluated on a semantic model of the SP K I/SD SI sy ste m. Th e policy a na ly sis proble m w ou ld re sou rc e R. be spe c ifi e d a s a F TP L formu la f w h ic h is inte rpre te d Th e sy nta x of th e log ic is ind u c tiv e ly d e fi ne d a s on a g iv e n se t of c e rtifi c a te s a t a pa rtic u la r insta nc e of follow s: time . Use rs c a n c h oose a pplic a tion d e pe nd e nt se ma ntic s for th e la ng u a g e , bu t w e u se th e sta nd a rd tu ple re d u c tion 1 )) If i ∈ K ∪ V , j ∈ T ∪ V , d ∈ {0, 1} a nd e ⊆ A se ma ntic s [CE E + 0 1 ] w ith th e v iew of SP K I a s a tru st th e n authoriz e(i, j, d, e) is a F TP L formu la . ma na g e me nt sy ste m. Th e c onstru c ts of th e log ic d e a l 2 ) If p ∈ N a nd q ∈ T ∪ V th e n resolve(p, q) is a w ith th e issu e s of a u th oriz a tion, na ming a nd v a lid ity . F TP L formu la . Th ou g h w e mod e l time a s d isc re te in th is pa pe r, w e c a n 3 ) If f a nd g a re formu la s of th e log ic , th e n ¬f a nd e a sily ex te nd F TP L to inte rpre t ov e r c ontinu ou s time . f ∧ g a re a lso F TP L formu la s. Th e a u th oriz a tion re a c h a bility issu e is mod e le d by th e 4 ) If f a nd g a re formu la s of th e log ic Xf, f U[t1 ,t2 ] g , pre d ic a te authoriz e(i, j, d, e), c a lle d th e a u th oriz a tion a re a lso F TP L formu la s. re a c h a bility pre d ic a te , w h e re i is a k ey or a v a ria ble 5 ) If f is a formu la of th e log ic th e n (∃if (i))is a lso a nd j is a fu lly q u a lifi e d na me or a noth e r v a ria ble . a F TP L formu la . Th e c ompone nts of authorize pre d ic a te d, e spe c ify th e d e leg a tion a nd a u th oriz a tion rig h ts re spe c tiv e ly . Th e A v a ria ble i is bou nd in a formu la f , if ev e ry boole a n d e leg a tion c ontrol d ∈ {0, 1}, w ith 1 imply ing oc c u rre nc e of i in f is in th e sc ope of a q u a ntifi e r pe rmission to a c c e ss a nd d e leg a te a nd 0 ju st g ra nting ov e r i. If i oc c u rs in f a nd is not bou nd th e n w e a c c e ss. Th e a u th oriz a tion c ontrol e is a su bse t of a c a ll i a fre e v a ria ble of f . W e u se fre e v a ria ble s in se t of c onsta nts A, w h ic h spe c ifi e s th e se t of a u th o- th e formu la to formu la te q u e rie s ov e r a SP K I sy ste m. riz a tion a c tions for a pa rtic u la r re sou rc e . Th e pre d ic a te Th e formu la w ill re tu rn a se t of ev a lu a tions w h ic h authoriz e(i, j, d, e) is tru e a t a pa rtic u la r insta nc e of w h e n su bstitu te d for th e fre e v a ria ble s w ou ld ma k e time t w ith re spe c t to a g iv e n se t of c e rtifi c a te s C, th e log ic a l formu la tru e in th e c ontex t of th e g iv e n if th e re is a c h a in of c e rtifi c a te s, w h e re th e princ ipa l c e rtifi c a te sy ste m C a t a pa rtic u la r insta nt of time t. d e note d by i d ire c tly /ind ire c tly tra nsfe rs th e rig h ts d, e F or a formu la f , le t f ree-var(f ) d e note th e se t of fre e to th e princ ipa l or na me d e note d by j . N a me c e rtifi c a te s v a ria ble s of f . A n ev a lu a tion sa y ρ for th e formu la f is a re not ju st me c h a nisms to re solv e na me s to princ ipa ls a ma pping from f ree-var(f ) to th e se t of princ ipa ls, bu t c a n a lso be u se d to d e leg a te pe rmissions [L i0 0 ]. To ρ : f ree-var(f ) → K. W e ex te nd th e d oma in of ρ to re a son ex c lu siv e ly a bou t na me re solu tion w e d e fi ne th e (f ree-var(f ) ∪ T ) so th a t for ev e ry T ∈ T , ρ(T ) = T . pre d ic a te resolve(p, q) w h e re p is e ith e r a loc a l or a n A n inte rpre ta tion for a formu la f is a triple (C, t, ρ) ex te nd e d na me a nd q is e ith e r a fu lly q u a lifi e d na me w h e re C is a se t of c e rtifi c a te s, t ≥ 0 is a time insta nc e or a v a ria ble . Th e pre d ic a te re a sons w h e th e r th e na me a nd ρ is a n ev a lu a tion. d e note d by p re solv e s to th e te rm d e note d by q u sing th e na me c e rtifi c a te s g iv e n in C . Th e ty pe of a v a ria ble W e g iv e th e se ma ntic s of a formu la f ov e r a n in- in c a se of both authoriz e a nd resolve is th e se t of te rpre ta tion (C, t, ρ). F or a ny c e rtifi c a te C le t C.val be a ll princ ipa ls in th e sy ste m. Th e only a tomic formu la s th e v a lid ity time inte rv a l of C . F or a g iv e n se t C of of th e log ic , a re th e a u th oriz a tion re a c h a bility pre d ic a te c e rtifi c a te s a nd time t, le t Ct = {C ∈ C|t ∈ C.val}. Ct authoriz e(i, j, d, e) a nd th e na me re solu tion pre d ic a te d e note s th e se t of c e rts v a lid a t time t a nd PCt (Q, Γ, δ, v) resolve(p, q). Th e re st a ll formu la s a re c ombina tions d e note s th e P D S c onstru c te d from th e se t of c e rts Ct a s of th e pre d ic a te s w ith th e a ssoc ia te d F TP L ope ra tors. d e sc ribe d in prev iou s se c tion. Th e ope ra tors of th e log ic c onsist of th e u su a l boole a n W e d e fi ne th e sa tisfi a bility re la tion |= be tw e e n a n c onne c tiv e s ¬ and ∧, th e te mpora l nex ttime ope ra tor inte rpre ta tion a nd a F TP L formu la a s follow s: X, th e bou nd e d u ntil ope ra tor U[t1 ,t2 ] w h e re t1 , t2 a re positiv e integ e rs a nd t1 ≤ t2 , th e princ ipa l q u a ntifi e r (C, t, ρ) |= authoriz e(i, j, d, e) if th e P D S ∃ w h e re th e u niv e rse of d isc ou rse is th e se t of princ i- c onstru c te d from se t of c e rtifi c a te s Ct , PCt c a n g o from pa ls(k ey s) pre se nt in th e c e rtifi c a te sy ste m C, ov e r w h ic h c onfi g u ra tion hρ(i), ⁄i to th e c onfi g u ra tion hρ(j), ⁄i, th e formu la s of th e log ic a re inte rpre te d . Th e se a re th e w ith a u th oriz a tion v a ria ble v ⊇ e, a t th e e nd of th e ba sic ope ra tors. W e a ssu me w e h av e se t V of v a ria ble s. c ompu ta tion, w h e n d = 1 i.e . hρ(i), ⁄i ⇒∗ hρ(j), ⁄i. A ll th e v a ria ble s ra ng e ov e r th e se t of princ ipa ls pre se nt If d = 0 th e P D S PCt c a n re a c h e ith e r th e a bov e in th e g iv e n c e rtifi c a te se t C. L e t K,T be th e se t of k ey s c onfi g u ra tion or th e c onfi g u ra tion hρ(j), ¥i. a nd te rms pre se nt in c e rtifi c a te se t C re spe c tiv e ly a nd N ote th a t if th e k ey ρ(i) d ire c tly /ind ire c tly issu e s te rm A be th e se t of a u th oriz a tion a c tions for a pa rtic u la r ρ(j) w ith g re a te r d e leg a tion a nd a u th oriz a tion rig h ts than specified by d and e respectively, the authorize authorize(R; x; 1; {r}); where x is a free variable, predicate still holds true. denotes a query which returns all the principals x who have the permission to delegate right r of the resource (C; t; ‰) |= resolve(p; q) if the PDS PCt can go R at the current instance of time. from configuration corresponding the name p, to the configuration corresponding the term ‰(q). B. Using the Logic to analyze the state of a given SPKI system (C; t; ‰) |= ¬f iff (C;t; ‰) 2 f All the formulas are evaluated in the context of a given certificate set C and with respect to a particular (C;t; ‰) |= f ∧ g iff (C;t; ‰) |= f and (C;t; ‰) |= g resource R unless otherwise specified. Constructing the required set of certificates C for evaluating a (C;t; ‰) |= Xf iff (C;t + 1; ‰) |= f . formula in a distributed environment is non-trivial. Xf is true at an instance of time t iff f is true in the Like others [CEE+ 01], [JR02] we assume that we next instance of time t + 1. have the required set of certificates to evaluate the formulas of the logic. Distributed database lookup and (C;t; ‰) |= f U[t1 ,t2 ] g iff ∃t0 ∈ [t + t1 ; t + t2 ] such goal-based certificate discovery methods seem to be that (C;t0 ; ‰) |= g and ∀t00 : t ≤ t00 < t0 (C;t00 ; ‰) |= f . promising approaches in retrieving the required set of f U[t1 ,t2 ] g is true at time t, iff formula f is true from certificates dynamically, especially for the SDSI part of time t to t0 , where at t0 , g will be true and t0 − t should the system [LWM01]. be within bounds of [t1 ; t2 ]. From the perspective of a resource administrator a (C;t; ‰) |= ∃if (i) iff there exists an K1 ∈ K such practical guideline seems to be to cache all the certificate that (C;t; ‰0 ) |= f (K1 ) where ‰0 is a restriction of chains which are presented as a proof of compliance by the domain of ‰ to (f ree-var(f (K1 )) ∪ T ): the access requesting clients. The resource administrator may cache these certificates in a secure storage and For convenience of expression we introduce derived use the FTPL logic as a means of offline Policy Audit. operators ∨; ♦; ¤; ∀; / which are extensions of the basic Though the view that certificates don’t exist till they are FTPL operators. used seems to be suited for policy audit, it can have unanticipated results as we show with an example later f ∨ g ≡ ¬(¬f ∧ ¬g) in the section. The language FTPL can be used in two ♦[t1 ,t2 ] f ≡ T rue U[t1 ,t2 ] f analysis modes with respect to time. By defining the origin of time “ 0” to be current time instance, we can ¤[t1 ,t2 ] f ≡ ¬3[t1 ,t2 ] ¬f reason about the current state of the policy. For auditing ∀if (i) ≡ ¬∃i¬f (i) a set of policy statements made from a particular time t in the past we can time shift the origin of time to t. ∃i / G f (i) ≡ ∃i(resolve(G; i) ∧ f (i)) We now illustrate the use of language to specify policy ∀i / G f (i) ≡ ∀i(resolve(G; i) ⊃ f (i)) analysis problems. This formula specifies that at every instance during ∨ is the standard propositional operator. ♦; ¤ are the the period [t1 ; t2 ] atleast one principal in the set defined standard temporal logic operators. ∀ is the universal by fully qualified name G has ‘w’ access to resource R quantifier. / is the name resolution operator. ♦[t1 ,t2 ] f (Group availability property): states whether f is true during any time instance from t1 ¤[t1 ,t2 ] ∃i / G authorize(R; i; 0; {w}) to t2 . ¤[t1 ,t2 ] f states whether formula f is true through- out time interval t1 ; t2 . Intuitively the name resolution This formula specifies whether a blacklisted principal operator / resolves a name (local or extended) to its KB ever had ‘read’ access to a resource R during the principals according to the SDSI name resolution prin- time of audit [0; ta ]. Here “ 0” refers to the start time of ciples and then evaluates the formula over the restricted the audit, and “ ta ” the end time of the audit: domain. ♦[0,ta ] authorize(R; KB ; 0; {read}) Given a formula f with free variables and a set of This formula specifies that principal K will be able certificates C and a time instance t, we interpret the to delegate ‘read’ right for the file R in future: formula f as a query returning a set of tuples, which are evaluations satisfying the formula f . For example ♦[0,∞] authorize(R; K; 1; {read}) This formula specifies that given resource R and name different set of certificates for different subcomponents G; there is an authorization chain granting G permissions of the formula. to perform action ‘w’ on R at current time: This query returns all the principals who will be excluded from performing action ‘w’ currently on the authorize(R; G; 0; {w}) resource R if all the certificates issued by a compromised This formula specifies that given resource R and name key K , CK ⊆ C are revoked now. G; all the principals denoted by G are authorized to {x| (C; 0; ∅) |= authorize(R; x; 0; {w})}− perform action ‘w’ on R at current time: {x| (C − CK ; 0; ∅) |= authorize(R; x; 0; {w})} ∀i / G(authorize(R; i; 0; {w})) Certain problems like “ is there a authorization chain Note that the later formula implies the former, but not from the resource R to a principal K without involving vice versa. the compromised key K 0 ” , are not directly expressible in This formula specifies that both the principals the logic FTPL. By using the above mentioned method K1 and K2 have simultaneous ‘write’ access to a we can still answer such questions. resource R at some time in the future(mutual exclusion): ♦[0,∞] [(authorize(R; K1 ; 0; {write})∧ Reasoning about roles in a SPKI system. Li [Li00]states that local names in the SPKI framework authorize(R; K2 ; 0; {write}))] can be interpreted as “ distributed roles” . Distributed in This formula specifies that both the principals the sense that they are not specified by a centralized K1 and K2 have ‘write’ access to a resource R at authority in the traditional sense of the roles. Roles are some time in the future: thought of as an abstraction for a set of users and a set of permissions, they can include other roles too [San98]. ♦[0,∞] (authorize(R; K1 ; 0; {write})∧ Roles can be implemented in a SPKI system using ♦[0,∞] authorize(R; K2 ; 0; {write})) local names by giving permissions directly to local names instead of principals. Principals inherit privileges This formula specifies that a principal belonging to lo- by virtue of being members of a “ local name” . This cal name Kf oo Accountant is directly/indirectly granting approach is useful to simplify policy specification in write permissions for a resource at some point of time many real-world scenarios. We can use FTPL to reason to a principal of local name Kf oo P urchaser (conflict about the interpretation of local name as roles. The of interest). predicate resolve can be used to reason about role membership and role hierarchy specified in a distributed ♦[0,∞] ∃i; j(authorize(i; j; 0; {write})∧ fashion. The following formula specifies that role corresponding local name R2 dominates that of R1 : resolve(Kf oo Accountant; i)∧ resolve(R1 ; R2 ) resolve(Kf oo P urchaser; j)) Static separation of duty: This formula specifies that Given resource R , this query returns all the principals two roles R1 and R2 have the same user as a member authorized to perform actions ’r’ and ’w’ on R at time in both the roles at same time. ta : 3(ta ,ta ) authorize(R; x; 0; {r; w}): ♦[0,∞] ∃i((resolve(R1 ; i) ∧ resolve(R2 ; i)) Where x is the free variable which returns all valuations Containment: This formula specifies that there is a satisfying the above formula. principal not contained by role R having ‘r’ access to a resource P at any point of time: This formula specifies whether principal K1 can ac- ♦[0,∞] ∃i (authorize(P; i; 0; {r}) ∧ ¬ resolve(R; i)) cess resource R before K2 : ¬authorize(R; K2 ; 0; {r}) U[0,∞] We can also use FTPL to reason about trust violations in a SPKI system. Consider the following scenario : authorize(R; K1 ; 0; {r}) A resource KU niv in a university, which the students All the previous properties and queries assumed that in CS and ECE dept need to have read access, some we evaluate the formula against a single certificate teaching assistants and special students(say research system C: In the following query we need to consider assistants) in CS dept also need to have a write access. But no non-CS student is supposed to have a write certificate has been issued in violation of the policy, that access to the resource. Given that it is not possible certificate has not been used. In this case the serious to specify negative permissions in a SPKI system the problems which arise because of evaluating a formula resource administrator has to trust that the principals on a partial state of the system are due to lack of name with delegation authority will not violate the university certificates. Goal directed algorithms for retrieving the policy. distributed set of SDSI name certificates already exist in the literature [LWM01]. (KU niv , KCSD ept students, {read}, 0, {t1 , t2 }) (KU niv , KE CE D ept students, {read}, 0, {t1 , t2 }) V. E VALUATING THE FORMULAS (KU niv , KCSD ept , {read, write}, 1, {t1 , t2 }) : So that In this section, we give an algorithm that takes a the CS dept admin can give write permissions to certificate system C and a FTPL formula f and outputs a selected TA’s and some special CS students. set of pairs of the form (ρ, t) such that f is satisfied with (KCSD ept , KT A1 , {read, write}, 0, {t1 , t2 }) respect to the evaluation ρ at time t, i.e., (C, t, ρ) |= f . (KCSD ept , KT A2 , {read, write}, 1, {t1 , t2 }) : TA2 can For ease of presentation of the algorithm, we assume give write permission to some special CS students. that there is only one resource and one access right. It (KCSD ept , students, Kstudenti , {t1 , t2 }) : Name can be easily generalized to the case of multiple access Certificate for CS student ’i’ including TA’s and special rights. If f has k free variables, the algorithm actually CS students. computes a relation Rf which is a set of (k + 1)- tuples such that the first k values in each tuple define In the above system the CS admin or TA2 can violate an evaluation ρ and the last value in the tuple is a list of the “ university policy” by giving permissions to a non- time intervals such that for all instances t in these time CS student. intervals (C, t, ρ) satisfies f . Actually, we compute the The university resource admin wants to check whether relations Rg for each subformula g of f . These relations there is a Non-CS student having write access to the are computed inductively in increasing lengths of g . In resource. the base case, g is an atomic subformula which is of the form authorize(i, j, d, e) or is of the form resolve(p, q). ♦[0;∞] ∃i [(authorize(KU niv , i, 0, {write})∧ Recall that for the atomic formula authorize(i, j, d, e), ¬resolve(KCSD ept students, i)] i can be a variable or a key, and j can be a variable or a term. We assume that j is a variable or a key (if j is a Evaluating a FTPL formula on a partial set of term then by introducing new keys and new rules we can certificates. reduce it to a case where j is a key. For example in order In the case where we evaluate the above formula over a to evaluate a predicate authorize(K1 , K2 A1 , d, e) over set of certificates obtained by caching the previous access certificate set C, we add new key K3 and a new rule request chains we may get a false-positive. Consider the K2 A1 → K3 and evaluate authorize(K1 , K3 , d, e) in scenario where TA2 from start uses the following chain the augmented system. The total number of new symbols to get resource authorization, and rules we introduce is bounded by the sum of right [(KU niv , KCSD ept , {read, write}, 1, {t1 , t2 })◦ hand sides of the certificate rules). Similarly we assume that in resolve(p, q), p can be a name and q can be (KCSD ept , KT A2 , {read, write}, 1, {t1 , t2 })] a key or a variable. In the first step of our algorithm, then the name cert validating TA2 to be a student of we compute the relations Rg for the case when g is CSDept is not cached by the resource administrator lead- an atomic formula. In the second step, we compute the ing to a false positive. When the resource administrator relations Rg for the case when g is not atomic. catches a possible policy violation he can use manual In the first step, the algorithm operates as follows. resolution or a goal-directed procedure to confirm the Recall that each certificate in the set C is associated result. The other type of violations are caused by lack of with a valid interval. We assume that tmin and tmax , authorization certs, for example when a principal grants respectively, are the minimum of the beginning points permissions to a blacklisted principal, but the blacklisted and the maximum of the end points of the validity principal doest not access the resource and no chain intervals of certificates in C. Let m be the number involving the blacklisted principal is sent as a proof of of certificates in C. Using the validity intervals of the authorization, then the corresponding formula evaluated certificates, we compute a sequence of increasing times over the cached set of certs returns a false answer. But T0 , T1 , ..., Tl−1 (These sequences can be easily computed this is a benign violation in the sense that though a from the sequence obtained by taking the begin and end times of all the validity intervals of certificates in C and principals in one structure from which the required sorting them in increasing order) and a sequence of sets relations can be computed efficiently. The And-or graph of certificates C0 ,...,Cl−2 such that l ≤ 2m, T0 = tmin , H can be computed directly from C without constructing Tl−1 = tmax + 1 and for each i, 1 ≤ i < l, the set of either of P or G . However, their definition gives a better certificates in C that are valid at every time instance in intuition leading to an easy proof of correctness of the the interval [Ti , Ti+1 − 1] is the same and is given by Ci . algorithm. We can see that the complexity of the above procedure is The given certificate system D is expressed as a set dominated by the complexity for sorting the time points of rewriting rules, the name certs correspond to the and hence is O(m log m). rules of form K1 A → K2 A1 A2 ...An . The auth certs For each i = 0, ..., l − 2 we do as follows. Using correspond to rules of the form K ¤ → K1 A1 A2 ..An ¤. the set of certificates Ci , for each atomic formula g Corresponding to each key K we introduce two symbols of f we do as follows. Consider the case when g is K ¤, K ¥. K# is the augmented set of keys consisting authorize(p, q, d, e). In this case, both p, q are either of the original keys and their associated symbols. a variable or a key. We compute the set E valg,i of evaluations ρ for g such that the following property is Given the set D of cert rules, all the rules will be satisied: if d = 1 then the the PDS PCi can go from the converted to a normalized transition function δ of a configuration hρ(p), ¤i to the configuration hρ(q), ¤i; if pushdown system. The pushdown system P we consider d = 0 then the PDS can go to the above configuration is a three tuple (Q, Γ, δ). Q is the set of states as or to the configuration hρ(q), ¥i. Note that if p is not given below, Γ is the stack alphabet containing identifiers a variable then ρ(p) = p; similar condition holds for and delegation symbols of a SPKI system, δ ⊆ Q × q . If neither of p, q is a variable then ρ is the empty {Γ ∪ {²}} × Q × {Γ ∪ {²}} is the transition function. evaluation; in this case either E valg,i contains the empty δ can have transitions either of type (K1 , A1 , K2 , ²) or evluation indicating the satisfaction of g at every time (K1 , ², K2 , A1 ), which means that PDS can go from instance in the interval [Ti , Ti+1 −1] or it is the empty set state K1 to state K2 either by popping or pushing a indicating the non-satisfaction of g in the above interval. symbol A1 ∈ Γ on top of the stack. ² is the empty string If g is resolve(p, q) then we compute the set E valg,i character. Thus in each transition a symbol is pushed or of evaluations ρ such that the above PDS can go from is popped from the stack and both do not occur in the the configuration corresponding to the name p to the same transition. Let li be the length of right hand side configuration corresponding to the term ρ(q) (recall that of rule i, LD the sum of the lengths of the right hand p has to be a name and q can be a variable or a term; side of the cert rules. also, recall that the configuration corresponding to the Q = K# ∪ {(i, j)| 1 ≤ i ≤ |D|, 1 ≤ j ≤ name of the form K A B is hK, A Bi). `i }, Γ = I ∪ {¤, ¥}. Each rewriting rule is con- Now it should be easy to see how Rg can be calculated verted into a set of four tuples in δ . If we have the from the sets E valg,i for i = 0, ..., (l − 2). Recall that, if i’th cert(name or auth) with length `i as Ki Ai → g has k free variables then Rg is a set of (k + 1) tuples Ki0 m(i,1) ...m(i,`i ) ; Ai , m(i,1) ...m(i,`i ) ∈ Γ, then it will (here k ≤ 2). For each evaluation ρ that appears in at be converted to normalized tuples of set δ as follows: least some E valg,i , Rg has a single tuple whose first k For each K , the PDS when in state K ¤ pushes ¤ onto components give the evaluation ρ and whose (k + 1)st the stack and goes to state K . component is the list of all time intervals [Ti , Ti+1 − 1] (K ¤, ², K, ¤) ∈ δ. such that ρ is in E valg,i . In the above procedure, we defined the sets E valg,i In a state K , the PDS non-deterministically chooses using a PDS PCi . However, we plan to employ a And-or a rule i whose left hand side key is K and and the left graph from which the sets E valg,i can be computed for hand side symbol(identifier or delegation bit) matches all g using a single fix point computation. the symbol on top of the stack, it pops the symbol Now we describe the And-or graph construction for currently on top of the stack and goes to state (i, li ) a set D of certificates. First using the certificate set D, if li > 0 or else if li = 0 to state Ki0 given by the right we first define a nondeterministic normalized pushdown hand side key of rule i. system P, from which we define an equivalent context ( K, Ai , (i, `i ), ² ) ∈ δ. free grammar G, which is converted in to an And-Or graph H. The advantages of using the And-Or graph ( K, Ai , Ki0 , ²) ∈ δ over the PDS model of Jha and Reps [JR02] is that In a state of the form (i, j) it pushes the j ’th identifier we have the reachability relationships between various of the right hand side of the i’th cert and goes to state (i, j − 1) if j > 1, else if j = 1 it goes to the state Ki0 edges is defined as follows. From each node of the form given by the right hand side key of rule i. [p, r, q] there are exactly two edges going to the vertices [p, r] and [r, q]. For each rule of the form Apq → Ars ( (i, j), ², (i, j − 1), m(i,j) ) ∈ δ f or all 2 ≤ j ≤ `i . in G , we have an edge from ([p, q] to [r, s]). For each ( (i, j), ², Ki0 , m(i,j) ) ∈ δ when j = 1. rule of the form Apq → Apr Arq in G , we have an edge from [p, q] to the vertex [p, r, q]. Note that there may be When the PDS is in state of type K and the top of cycles in the graph. the stack symbol is either ¤ or ¥ then it goes to state K ¤ or K ¥ respectively. Now, we compute a function F : V → {T rue, F alse} ¤ ¥ (K, ¤, K , ²) ∈ δ, (K, ¥, K , ²) ∈ δ which is the least fix point that satisfies the following conditions: for each vertex u of the form [p, p], F (u) = We can see that in a SPKI system D a key K1 gives T rue; for each vertex u of the form [p, q] (p 6= q ), F (u) authorization to another key K2 if the PDS P when is the disjunction of all F (v) such that (u, v) ∈ E ; for started in state K1¤ on an empty stack reaches either each vertex u ∈ V2 , F (u) is the conjunction of all F (v) of the states K2¤ or K2¥ with the stack empty at the end. such that (u, v) ∈ E . It is well known that this fix point It is easy to see that size of δ is O(LD + |D|) and can be computed in time linear in the size of H using size of Q is O(|K| + LD ). a simple iterative approach as follows. With each vertex u, we maintain a variable label(u) which is initialized to From the normalized PDS P we construct an equiva- T rue for vertices of the form [p, p] and is initialized to lent context free grammar G according to the rules given F alse for all other vertices. We also maintain a counter in [Sip01]. The variables (i.e., non-terminals) of G are c(u) with each vertex u which is initialized to zero for {Apq |p, q, ∈ Q}. The production rules of G are described all vertices. The algorithm also maintains a set X of below. vertices. Initially, X is the set of nodes of the form [p, p]. For each p, q, r, s ∈ Q and A ∈ Γ, such that δ After this we iterate the following procedure as long as contains the transitions (p, ², r, A), (s, ², A, q) (i.e., the X is non-empty. We delete a node v from X , examine first transition pushes A onto the stack while the second all nodes u from which there is an edge to v ; if u ∈ V1 pops the same symbol from the stack) we have the rule (i.e.,is an or-node) and c(u) is zero then we increment Apq → Ars in G. c(u), set label(u) to T rue and add u to the set X ; if For each p, q, r ∈ Q we have the rule Apq → Apr Arq u ∈ V2 (i.e., is an “ and” node) and c(u) < 2 then we in G . increment c(u), further if c(u) = 2 after this increment, For each p ∈ Q, we have the rule App → ² in G . we set label(u) to T rue and add u to X . It is easily shown that at the end of the above algo- The only terminal symbol of the grammar is the null rithm, for any vertex u of the form [p, q], label(u) is string ². Let Q0 ⊂ Q be the set K∪{(i, li )| 1 ≤ i ≤ |D|}. T rue iff the contex free grammar G can generate the Due to the semantics of SPKI, it is easy to see that empty string ² from the non-terminal Apq . Using this and among the rules of type Apq → Apr Arq , the ones that the results of [Sip01], the following theorem is easily are useful are those in which q, r ∈ Q0 . It is easy to proved. see that the number of rules of this type is bounded by Theorem: At the end of the above algorithm, for any O((|K| + LD )(|K| + |D|)|D|). The total number of rules vertex u of the form [p, q], label(u) = T rue iff the PDS is O((|K| + LD )(|K||D| + |D|2 )). The CFG G has the when started in state p with empty stack reaches state q following property. The PDS P can go from state p to q with empty stack. starting and ending in a empty stack iff we can generate The size of H which is (|V | + |E|) can be shown the empty string ² from CFG symbol Apq . The term to be O((|K| + LD )(|K||D| + |D|2 )). Thus the reachability problem of the PDS has been converted to complexity of the above fix point computation is a word problem in the CFG. O((|K| + LD )(|K||D| + |D|2 )). From the above grammar G we construct a directed And-Or graph H = (V, E). The vertex set V is a Recall that, at the beginning of the section, we de- disjoint union of two sets V1 , V2 . V1 is the set of all scribed a method for computing relation Rg for each pairs of the form [p, q] where p ∈ Q and q ∈ Q0 . V2 is atomic formula g . This procedure used a sequence of the set of all triples of the form [p, q, r] where p ∈ Q sets of certificates C0 , C1 , ..., Cl¡2 where l ≤ 2,. and q, r ∈ Q0 . Each vertex in V1 is an “ or” vertex while Rg is constructed by computing Evalg,i for i = 0...l− each vertex in V2 is an “ and” vertex. The set E of 2. It should be easy to see that, for any fixed i, Evalg,i for all g can be computed by constructing the And-or preserve this property. The union of two normalized lists graph corresponding to the set of certs Ci . L1 and L2 is another normalized list covering exactly the Evalg,i can be computed from the And-or graph Hi union of the time points covered by the two lists. The corresponding to the set of certificates Ci as follows. intersection of two normalized lists is a normalized list Assume g is authorize(p, q, d, e). If both p, q are that covers exactly the time points common to both of the variables and d = 1 then Evalg,i is the set of all pairs lists. The union and intersection of two normalized lists (K1 , K2 ) such that the vertex (K1¤, K2¤) is labeled T rue can be computed in time proportional to the sum of the in graph Hi . If d = 0 then we check if either the above sizes of the two lists. The complement of a normalized vertex or the vertex (K1¤, K2¥) are labeled T rue in Hi . If list L1 is a normalized list that covers exactly all time both p, q are keys say K1 , K2 and d = 1, then Evalg,i is points in the interval [0, ∞] that are not covered by the singleton set containing the empty evaluation if the L1 . The complement of a normalized list can also be vertex (K1¤, K2¤) is labeled T rue; otherwise, it is the computed in time linear in the size of the list. empty set. Other cases are similarly handled. Now we give the second part of the algorithm based Assume g is resolve(p, q). In this case p is a name on structural induction for computing relation Rg of and q can be a key or a variable. We can assume that a subformula g when g is not atomic. The algorithm p is the prefix of the right hand side of some rule j in computes relation Rg for each subformula g of f in Ci (If this is not the case then we can add a dummy rule the increasing lengths of the subformula g . On termi- whose right hand side is p). Assume that the length of nation of the algorithm we have the required relation p(number of identifiers) is k . Rf . We call the list in each tuple of the relation Rg If q is a key then Evalg,i is the singleton set containing as the validity list of the tuple. We want to show the empty evaluation if the node [(j, k), q] in Hi is that the length of the validity list in each tuple of labeled T rue; otherwise, it is the empty set. If q is a in Rg is of length O(m|g|). To show this, we first variable then Evalg,i is the set of all K1 such that the define a finite set of time points (i.e., positive inte- node [(j, k), K1 ] in Hi is labeled T rue. gers), called extreme points(g), such that the beginning In the above computation if Ci+1 ⊇ Ci , then the and ending time points of each interval in the validity graph Hi+1 is obtained by adding new edges to Hi , lists of tuples in Rg belong to extreme points(g). corresponding to additional certs in Ci+1 . The fixpoint The set extreme points(g) is defined inductively on computation on Hi+1 can start with the labels computed the structure of g . If g is an atomic proposition then for Hi and continue with the additional edges till a new extreme points(g) is the set of points {Ti , Ti + 1 : fixpoint is reached. Thus we can take advantage of the 0 ≤ i < l} as given at the beginning of this section. incremental nature of the fix point computation, with It is to be noted the cardinality of this set is O(m). respect to addition of edges to the And-or Structure. It If g = h ∧ h0 then extreme points(g) is the union of is to be noted that if Ci+1 ⊆ Ci , then Hi+1 is obtained extreme points(h) and extreme points(h0 ). If g = ¬h from Hi by deleting some edges. However we cannot then extreme points(g) is same as extreme points(h). apply incremental computation while deleting edges in If g = Xh then extreme points(g) is the set {0, t − the graph Hi , as the lest fixpoint computation is not 1 : t ∈ extreme points(h)}. If g = hU[t1 ,t2 ] h0 , incremental with respect to the deletion of edges in the then extreme points(g) is the set {t − t1 , t − t2 , t + And-or structure. 1 − t1 , t + 1 − t2 : t ∈ extreme points(h) or Since |Ci | ≤ m, from the above analysis we can see t ∈ extreme points(h0 )}. If g = ∃ i(h) then that Rg , for any atomic g , can be computed in time extreme points(g) is same as extreme points(h). By O(m(|K| + |LC |)(Km + m2 )). induction on the length of g , it can be shown that the cardinality of extreme points(g) is O(m|g|). In the In our algorithm presented below for computing Rf , construction of Rg given below, it should be easy to we need to maintain lists of intervals of time. A list of see that the begin and end points of each interval in intervals is maximal if every pair of intervals in the list the validity list of each tuple in Rg is from the set is non-overlapping and non-adjacent (two time intervals extreme points(g). Since the intervals in a validity list [s, s0 ], [t, t0 ] are non-overlapping and non-adjacent if t > are disjoint, each point in extreme points(g) can appear s0 + 1 or s > t0 + 1). We maintain all lists in such as the end point of atmost one interval. Hence, the length a way that they are maximal and the intervals are in of each such validity list is O(m|g|). sorted order. We call such lists as normalized. We define Let |Rg | denotes the number of tuples in the relation the size of such a list as the number of intervals in it. Rg corresponding to a formula g . As shown above, the All our lists are in normalized form and all operations length of any validity list of a tuple in Rg is of O(m|g|) where m is the number of certificates. Since the number Consider a subformula g = hU[t1 ,t2 ] h0 , where Rh , Rh0 of free variables appearing in g is at most |g|, we see are the relations computed for formulas h and h0 , having that the size of any single tuple including its validity list (i + 1) and (j + 1) attributes respectively. If h, h0 have v is O(|g| + m|g|) which is O(m|g|). Hence, the size of number of common variables, then Rg has (i+j −v +1) Rg is O(m|Rg ||g|). attributes. For a given instantiation ρ of values if h is If the subformula g is of the type ¬h, then for every satisfied during the times given by validity list L1 , h0 is tuple of form (K1 , K2 , ..., Kr , L) ∈ Rh we include the satisfied during the time intervals given by the validity tuple (K1 , K2 , ..., Kn , L) in Rg . L is the complement of list L2 , we give a method to calculate L12 the list of the validity list L as defined earlier. As shown previously time intervals during which g is satisfied. We define two we can compute L in time linear in the size of the list intervals [p1 , p2 ] ∈ L1 , [q1 , q2 ] ∈ L2 as compatible if L. Hence we can compute Rg in time O(m|Rh ||h|). they overlap or if [p1 , p2 ], [q1 , q2 ]are adjacent i.e. q1 = Consider a subformula g = h ∧ h0 , where Rh , Rh0 are p2 + 1. To compute L12 take two compatible intervals the relations computed for formulas h and h0 , having I1 = [p1 , p2 ] ∈ L1 , I2 = [q1 , q2 ] ∈ L2 , then by the (i + 1) and (j + 1) attributes respectively. If h, h0 have v definition of the bounded until operator we can show number of common variables, then Rg has (i+j −v +1) that the corresponding interval I12 ∈ L12 during which attributes. For a given instantiation ρ if h is satisfied the formula g holds good is [max(T − t2 , p1 ), max(T − during an interval I (in the validity list) and h0 during I 0 , t1 , p1 )] where T = min(p2 + 1, q2 ). Thus we compute g is satisfied during time I ∩ I 0 . For a tuple t1 in Rh and all the intervals in L12 from the compatible intervals a tuple t2 in Rh0 , we include a tuple t12 in Rg , if the cor- of L1 and L2 . Given that we maintain the validity lists responding values of of the common variables in the two in a normalized condition we can calculate L12 in time tuples are equal and the intersection of the corresponding linear in the sum of sizes of validity lists L1 and L2 . validity lists is not empty. We include in the tuple t12 For a tuple t1 in Rh and a tuple t2 in Rh0 , we include all the values related to the variables(without repeating a tuple t12 in Rg , if the values of tuples corresponding the common variable values) and the validity list in the to the common variables are equal and the composition tuple t12 is given by intersection of the validity lists in of corresponding validity lists as defined above is not t1 and t2 . Given that we can compute the intersection of empty. We include in the tuple t12 all the values related two validity lists in time linear in the sum of their sizes, to the variables(without repeating the common variable we can compute Rg in time O(m|Rh ||Rh0 |(|h| + |h0 |)). values) and the validity list in the tuple t12 is given If the subformula is of the type g = Xh, then for by composition of corresponding validity lists in t1 every tuple in Rh of the form (K1 , ...Kr , L), we include and t2 as defined above. We can compute Rg in time the tuple (K1 , ...Kr , L0 ) in Rg where L0 is as defined O(|Rh ||Rh0 |m(|h| + |h0 |)). below; L0 consists of all intervals of the form [max(ti − Thus we calculate the relation Rf for the formula f 1, 0), tj − 1] such that [ti , tj ] ∈ L. We can compute L0 inductively from the components of the formula. Let n in time linear in the size of L. Hence we can compute be the total number of principals in the system, L the Rg in time O(m|Rh ||h|). sum of lengths of right hand side of all certificates and If the subformula is g = ∃ih(i), then Rg is computed k the number of variables in the formula f . For any as follows. Let r + 1 be the number of attributes of the formula g(i1 , ..., ili ) with li number of variables the size relation Rh . With out loss of generality, assume that the of relation Rg is of order O(nli m|g|) because each of the j th attribute of Rh gives the value of the variable i. Note variables can be any of the n principals in the system. that the values of the last attribute is the validity list of The normalized validity list of a tuple in Rg can be main- the tuple. We group the tuples of Rh into the smallest tained in the size of O(m|g|). The relation Rg obtained collection of groups G1 , .., Gl such that each group Gp by composition of relations Rh and Rh0 can be computed satisfies the following property: all the tuples in Gp have in time O(|Rh ||Rh0 |m(|h| + |h0 |)). If h contains li vari- the same values for the q th attribute, for each q such ables and h0 contains lj variables, Rg can be computed that q 6= j and 1 ≤ q ≤ r. Corresponding to each group in time O(nli nlj m(|h| + |h0 |)) = O(nli +lj m(|h| + |h0 |)). Gp , Rg has a single tuple (K1 , .., Kj−1 , Kj+1 , ..., Kr , L) Thus the overall formula can be computed in time where Kq , for 1 ≤ q ≤ r and q 6= j , is the value of the O(nli +lj +... m(|h| + |h0 | + ...)) = O(nk m|f |). Since the q th attribute in a tuple in Gp and L is the union of all size of formula |f | ≈ k the complexity of evaluating the the validity lists in the tuples in Gp ; it is to be noted that formula f given the relations for the atomic formulas the list L can be computed in time linear in the sum of authorize and resolve is O(n|f | m|f |). The overall the sizes of the validity lists in the tuples of Gp . Hence complexity of evaluating the formulas of the logic FTPL we can calculate Rg in time O(m|Rh ||h|). is O(n|f | m|f |) + O(m(n + L)(nm + m2 )). VI. C ONCLUSION AND F UTURE W ORK [JR01] Somesh Jha and Thomas Reps. Analysis of spki/sdsi certificates using model checking. In 15th IEEE Com- In this paper, we have proposed a language for ana- puter Security Foundations Workshop, pages 129 144, lyzing a set of policy statements labeled with validity Cape Breton, Canada, 24 26 June 2001. IEEE Computer intervals and gave a list of problems that could be Society Press. [JR02] S. Jha and T. Reps. Analysis of spki/sdsi certificates specifiable by the language. We also gave algorithms using model checking. In Computer Security Foundations for computing the formulas of the logic in a incremental Workshop (CSFW), June 2002. fashion. In future we propose to modify the semantics of [Li00] Ninghui Li. Local names in SPKI/SDSI. In Proceed- ings of the 13th IEEE Computer Security Foundations the modal operators of FTPL to consider a state transition Workshop, pages 2 15. IEEE Computer Society Press, model for the SPKI access control system. jul 2000. [LM03] Ninghui Li and John C. Mitchell. Datalog with con- straints: A foundation for trust management languages. R EFERENCES In Proceedings of the Fifth International Symposium on Practical Aspects of Declarative Languages, January [Aba97] Martin Abadi. On SDSI’s linked local name spaces. 2003. To appear. In PCSFW: Proceedings of The 10th Computer Security [LWM01] Li, Winsborough, and Mitchell. Distributed credential Foundations Workshop. IEEE Computer Society Press, chain discovery in trust management. In SIGSAC: 8th 1997. ACM Conference on Computer and Communications Se- [ADT02] A. Arsenault, Diversinet, and S. Turner. Internet X.509 curity. ACM SIGSAC, 2001. Public Key Infrastructure: Roadmap. PKIX working [LWM03] Ninghui Li, William H. Winsborough, and Mitchell group-Internet Draft, 2002. Mitchell. Beyond Proof-of-Compliance: Safety and avail- [BEO97] A. Bouajjani, J. Esparza, and O.Maler. Reachability ability analysis in trust management. In Proceedings analysis of pushdown automata: application to model- of the 2003 Symposium on Security and Privacy, pages checking. Lecture Notes in Computer Science, 1243, 123 139, Los Alamitos, CA, May 11 14 2003. IEEE 1997. Computer Society. [BFIK99] Matt Blaze, Joan Feigenbaum, John Ioannidis, and An- [San98] R. S. Sandhu. Role-based access control. In gelos D. Keromytis. The role of trust management in M. Zerkowitz, editor, Advances in Computers, volume 48. distributed systems security. pages 185 210, 1999. Academic Press, 1998. [BFK99] Matt Blaze, Joan Feigenbaum, and Keromytis Keromytis. [Sip01] Michael Sipser. Introduction to the Theory of Computa- KeyNote: Trust management for public-key infrastruc- tion. PWS Publishing Company, 20 Park Plaza, Boston, tures. In Bruce Christianson, Bruno Crispo, William S. MA 02116, 2001. Harbison, and Michael Roe, editors, Security Protocols— 6th International Workshop, volume 1550 of Lecture Notes in Computer Science, pages 59 66, Cambridge, United Kingdom, 1999. Springer-Verlag, Berlin Ger- many. [CEE+ 01] Dwaine Clarke, Jean-Emile Elien, Carl Ellison, Matt Fre- dette, Alexander Morcos, and Ronald Rivest. Certificate chain discovery in SPKI/SDSI. Journal of Computer Security, 9(4), 2001. [EFL+ 99] Carl M. Ellison, Bill Frantz, Butler Lampson, Ron Rivest, Brian Thomas, and Tatu Ylonen. RFC 2693: SPKI Certificate Theory. The Internet Society, September 1999. See ftp://ftp.isi.edu/in-notes/rfc2693.txt. [EHRS00] Esparza, Hansel, Rossmanith, and Schwoon. Efficient algorithms for model checking pushdown systems. In CAV: International Conference on Computer Aided Veri- fication, 2000. [Ell99] Carl M. Ellison. RFC 2692: SPKI requirements. The Internet Society, September 1999. See ftp://ftp.isi.edu/in-notes/rfc2692.txt. [HK00] Jon Howell and David Kotz. A formal semantics for SPKI. In Proceedings of the Sixth European Symposium on Research in Computer Security (ESORICS 2000), volume 1895 of Lecture Notes in Computer Science, pages 140 158. Springer-Verlag, October 2000. [HRU75] Michael A. Harrison, Walter L. Ruzzo, and Jeffrey D. Ullman. On protection in operating systems. In Proceed- ings of the fifth ACM symposium on Operating systems principles, pages 14 24. ACM Press, 1975. [HvdM01] Joseph Y. Halpern and Ron van der Meyden. A logic for sdsi’s linked local name spaces. Journal of Computer Security, 9:105 142, 2001. Enhancing Security of Security-Mediated PKI by One-time ID Satoshi Koga1 , Kenji Imamoto1 , and Kouichi Sakurai2 1 Graduate School of Information Science and Electrical Engineering, Kyushu University 6-10-1 Hakozaki, Higashi-ku, Fukuoka, 812-8581, Japan {satoshi,imamoto}@itslab.csce.kyushu-u.ac.jp 2 Faculty of Information Science and Electrical Engineering, Kyushu University 6-10-1 Hakozaki, Higashi-ku, Fukuoka City, 812-8581, Japan sakurai@csce.kyushu-u.ac.jp Abstract. The Security Mediator (SEM) approach was proposed by Boneh et al. at USENIX Security Symposium in 2001. However, their Security-Mediated PKI has a drawback that it is vulnerable to Denial- of-Service (DoS) attacks, since an attacker can send a lot of requests to the SEM server. To prevent DoS attacks, some solutions are proposed. In this paper, we show that the use of Message Authentication Code (MAC), which is one of the solution proposed, cannot avoid DoS attacks because an attacker can reuse the request for replay attacks. In order to prevent DoS attacks efficiently, this paper proposes Security-Mediated PKI using one-time ID. Our proposed system can avoid DoS attacks and protect the privacy of signers, since one-time ID can be used only once. Keywords: Public Key Infrastructure, Certificate Revocation, Security Media- tor, One-time ID 1 Introduction 1.1 Background A Public Key Infrastructure (PKI) is the basis of security infrastructure whose services are implemented and provided using public key techniques. Most of the protocols for secure e-mail, web service, virtual private networks, and au- thentication systems make use of the PKI. In the PKI, a certificate is used to bind an entity’s identity information with the corresponding public key. When a certificate is issued, its validity is limited by a pre-defined expiration time. Nevertheless, certificates are revoked in case of breaking that binding before its expiration date. Thus, the certificate verifier must check not only the expiration date on the certificate but also the revocation information of it. A certificate revocation system can be implemented in several ways. The most well-known method is to periodically publish a Certificate Revocation List (CRL) 4th Annual PKI R&D Workshop Pre-Proceedings [6, 8], which is a digitally signed list of revoked certificates and usually issued by the Certification Authority (CA). One of the shortcomings of CRL systems is that the time granularity of revocation is constrained by CRL issuance periods. It is necessary to obtain timely information regarding the revocation status of a certificate. The most popular mechanism that provides real-time status of a certificate is the Online Certificate Status Protocol (OCSP) [13]. The OCSP provides the up-to-date response to certificate status queries. Since the user just requests to return the status of certificate, the communication costs can be reduced in comparison to the CRL. Recently, Boneh et al. observed that existing revocation techniques, including OCSP, don’t provide immediate revocation [3]. Supporting immediate revoca- tion with existing revocation techniques would result in heavy performance cost and very poor scalability. To provide immediate revocation, SEcurity Mediator (SEM) approach was proposed [2, 3]. The basic idea of SEM is as follows. They introduce a new entity, referred to as a SEM: an online semi-trusted server. To sign or decrypt a message, a client must first obtain a message-specific token from its SEM. Without this token, the user cannot accomplish the intended task. To revoke the user’s ability to sign or decrypt, the security administra- tor instructs the SEM to stop issuing tokens for that user’s future request. The SEM approach provides several advantages. This approach can eliminate the need for CRLs since private-key operations cannot occur after revocation. That is, this approach enables immediate revocation. Recently, Vanrenen et al. pro- posed a distributed SEM architecture [14], and Bicakci et al. proposed Privilege Management Infrastructure based on SEM approach [1]. 1.2 Motivation As Boneh et al. pointed out in [3], one of the drawbacks of SEM approach is that it is vulnerable to Denial-of-Service (DoS) attacks. The SEM server must generate the token for every user’s request. That is, for every simple request sent by an attacker, the SEM server must generate the token, which is a computa- tionally intensive operation. Consequently, it becomes highly vulnerable to DoS attacks. The goal of this paper is to prevent DoS attacks. 1.3 Related Work To prevent DoS attacks, there are some solutions as follows [3]. 1. Digital signatures The simple solution is to authenticate the user by verifying digital signature [3]. For example, a user can generate a partial signature on each request message as follows. (See Section 2.3 for notations.) hEC(m), EC(m)du mod ni The SEM computes a digital signature S(m) = (P Ssem ∗ P Su ) mod n and verifies it by using public key. Although this method does not prevent DoS 177 4th Annual PKI R&D Workshop Pre-Proceedings attacks, since a SEM would need to perform two modular exponentiations to authenticate each request [3]. 2. Secure Sockets Layer (SSL) Another solution is to rely on more general encapsulation techniques, such as SSL, to provide a secure channel for communications between SEMs and users [3]. However, the user must validate the SEM’s certificate in order to establish secure channel. Therefore, the burden of a user becomes heavy since the certificate validation processing is intensive operations. 3. Message Authentication Code (MAC) More cost-effective approach is to use MAC or keyed hash [3]. This situa- tion requires a shared secret key between a SEM and each user. This paper shows that this approach cannot prevent DoS attacks. An attacker can reuse requests generated by legal users, and send a lot of requests to a SEM. Even if the SEM authenticates requests by checking MAC, it is vulnerable to DoS attacks based on replay attacks, as discussed in Section 3. 4. The DoS resistant protocol To avoid DoS attacks from any malicious stranger, it is important to make him have a large burden in sending a lot of requests. One approach to solve the DoS problem is to make the client compute some form of proof of compu- tational effort [5, 12]. This approach is effective to DoS attacks, however com- putational costs of the legal user are also increasing as well as DoS attackers. In our proposed method, only attackers require exhaustive computations. 1.4 Our Contributions This paper shows that traditional solutions cannot prevent DoS attacks. An attacker can reuse requests generated by legal users, and send a lot of requests to a SEM. Even if the SEM authenticates requests by checking MAC, it is vulnerable to DoS attacks based on replay attacks. It is necessary to avoid DoS attacks based on replay attacks efficiently. This paper proposes the SEM approach using One-time ID. One-time ID is a user’s extraordinary identity, which has two properties as follows: (1) an attacker can- not specify who is communicating even when she eavesdrops on one-time ID, and (2) One-time ID can be used only once. Our proposed method requires a shared secret key between a SEM and each user. A user sends a request containing a message and one-time ID. One-time ID can be derived by shared secret key and be used only once. By checking one-time ID, a SEM server can confirm that requesting user is legal user. In our proposed method, the user sends a request containing Message Authentication Code (MAC). Therefore, an attacker cannot create the legal request. Moreover, an attacker cannot reuse requests for replay attacks because the One-time ID is used only once. Our proposed system has the following benefits. 1. DoS-resilient A SEM can efficiently detect illegal requests, since an attacker cannot gen- erate one-time ID unless she obtains a shared secret key. Moreover, our 178 4th Annual PKI R&D Workshop Pre-Proceedings proposed system can prevent replay attacks. An attacker cannot reuse the request generated by legal user because one-time ID can be used only once. 2. Efficiency One-time ID can be generated by hash computations. Therefore, computa- tional costs of a SEM and a user are more efficient, compared with signature- based solutions. Additionally, communications between a SEM and a user are the same as the existing Security-Mediated PKI. 3. Privacy In existing approaches, a user must send a request contained a public key certificate. Thus, an attacker can trace the user’s identity by tracking user’s request. It is easy to know the user’s private information (e.g. user’s name, affiliation, address and so on.) from the serial number of his certificate. In our proposed system, an attacker cannot trace user’s identity even if she eavesdrops on one-time ID, because one-time ID dynamically changes. That is, our proposed system can protect the privacy of signers, compared with existing approaches. The rest of this paper is organized as follows. In Section 2, we explain the SEM approach. In Section 3, we show that the traditional approach cannot prevent DoS attacks. In Section 4, we describe our proposed system and Section 5 discusses as to security of our proposed system. Concluding remarks are made in Section 6. 2 Security-Mediated PKI 2.1 Model In a Security-Mediated PKI, there are three entities, as shown in Fig.1. 1. Certification Authority (CA) A Certification Authority (CA) is a trusted third party that issues certifi- cates. Compromise of CA’s private key will affect the entire system, so the CA is isolated from the Internet to prevent unauthorized accesses. 2. SEM (SEcurity Mediator) A SEM is an online semi-trusted server. A single SEM serves many users. 3. User Users trust the CA and SEM. To sign or decrypt a message, they must first obtain a message-specific token from its SEM. 2.2 An overview of a SEM The basic idea of SEM approach is as follows [2]. We introduce a new entity, referred to as a SEM. A SEM is an online trusted server. To sign or decrypt a message, Alice must first obtain a message-specific token from the SEM. Without this token Alice cannot use her private key. To revoke Alice’s ability to sign or decrypt, the security administrator instructs the SEM server to stop issuing 179 4th Annual PKI R&D Workshop Pre-Proceedings @BA .C%&)7D=& )FEG,   ! "# $%&'  (  ! "*)+ ,&! ( %    - &.%) "   (&/  ' "0+ (1 2' ( % 3 &4 (165 %7.98:;2"   < '=>&? "   Fig. 1. A general SEM algorithm tokens for Alice’s public key. At that instant, Alice’s signature capabilities are revoked. Fig. 1 shows the general SEM algorithm. A SEM approach is to enable immediate revocation of user’s key. This method provides two additional benefits over standard revocation techniques: (1) sim- plified signature validation, and (2) enabling revocation in legacy systems. The SEM approach naturally provides the following semantics for digital signatures: Binding Signature Semantics: a digital signature is considered valid if the public key certificate associated with the corresponding private key used to gen- erate the signature was valid at the time the signature was issued. 2.3 Mediated RSA This section describes in detail how a SEM interacts with users to generate tokens. The SEM architecture is based on a variant of RSA called Mediated RSA (mRSA). The main idea is to split each RSA private key into two parts using simple 2-out-of-2 threshold RSA [4]. Each user U has a unique public key and private key. The public key P K includes n and e, where the former is a product of two large distinct primes (p, q) and e is an integer relatively prime to φ(n) = (p − 1)(q − 1). There is also a corresponding RSA private key SK = (n, d) where d ∗ e = 1 mod φ(n). However, as mentioned above, no one party has possession of d. Instead, d is effectively split into tow parts: du and dsem which are secretly held by the user 180 4th Annual PKI R&D Workshop Pre-Proceedings and the SEM, respectively. The relationship among them is: d = dsem + du mod φ(n) The CA generates a distinct set: {p, q, e, d, dsem , du } for the user. The first four values are generated as in standard RSA. The fifth value, dsem , is a random integer in the interval [1, n], where n = pq. The last value is set as: du = d − dsem mod φ(n). The protocol of key generation algorithm is as follows. Let k be a security parameter. After CA computes, dsem is securely communicated to the SEM and SK is communicated to the user. (Algorithm: key generation) (1) Generate random k/2-bit primes: p, q (2) n ← pq r ∗ (3) e ←− Zφ(n) (4) d ← 1/e mod φ(n) r (5) dsem ←− 1, ..., n − 1 (6) du ← (d − dsem ) mod φ(n) (7) SK ← (n, du ) (8) P K ← (n, e) 2.4 mRSA signatures According to PKCS #1v2.1 [11], RSA signature generation is composed of two steps: message encoding and cryptographic primitive computation. We denote by EC() the encoding function. This encoding includes hashing the input message m using a collision resistant hash function. EC() is the EMSA-PKCS1-v1 5 encoding function, recommended in [11]. 1. The user sends the message m to the SEM. 2. The SEM checks the user’s certificate. Only if this certificate is valid, the SEM computes a partial signature P Ssem = EC(m)dsem mod n, and replies with it to the user. 3. The user computes P Su = EC(m)du mod n. Then, the user receives P Ssem and computes S(m) = (P Ssem ∗ P Su ) mod n. It then verifies S(m) as a standard RSA signature. If the signature is valid, the user outputs it. 3 Disadvantages of a SEM approach One of the drawbacks of SEM approach is that it is vulnerable to Denial-of- Service (DoS) attacks, as pointed in [3]. There are three types of DoS attack: 181 against SEM’s bandwidth, memory, and CPU. The purpose of the first attack is that a SEM cannot receive any more messages. The second one is performed to make a SEM store large quantities of waste states. The last one is the attack which makes a SEM computes a lot of quite inefficient processings. In SEM approach, we focus on DoS attacks against SEM’s CPU. The SEM server must generate the partial signature for every user’s request. If an attacker can send a lot of requests, the SEM must compute a lot of partial signatures. Computations of a partial signature require a modular exponentia- tion. Consequently, it becomes highly vulnerable to DoS attacks. To prevent DoS attacks, the SEM authenticates incoming requests. Only if a legal user sends a request, the SEM computes a partial signature. The SEM does not respond any request, sent by a party whom the responder cannot specify. Additionally, the SEM should confirm that the request is fresh. If an attacker can eavesdrop on communications between a legal user and a SEM, she can reuse a request created by legal users for replay attacks. That is, an attacker can send a lot of legitimate requests to the SEM. To prevent DoS attacks based on replay attacks, the SEM only responds to new requests. In [3], several solutions are proposed. However, these solutions cannot prevent DoS attacks efficiently. Most cost-effective approach is to use Message Authenti- cation Code (MAC) or keyed hash [3]. This situation requires a shared secret key k between a SEM and each user. A SEM can authenticate the request by checking MAC. However, it is vulnerable to replay attacks. An attacker can reuse requests generated by legal users, and send a lot of requests to a SEM. Suppose that the le- gal user sends requests hM ACk (m1 ), m1 i, hM ACk (m2 ), m2 i, ..., hmn , M ACk (mn )i, as shown in Fig. 2. M ACk (mi ) denotes the MAC using shared key k as the in- put message mi . An attacker can eavesdrop these requests and send them to the SEM. This attack is called as replay attack. The SEM misunderstands that these request sent by an attacker are legal requests, and computes partial signatures, since the SEM cannot detect replay attacks. 4 Our proposed method In MAC approach proposed in [3], the SEM cannot detect replay attacks. Sup- pose that an attacker, who doesn’t know secret value, can eavesdrop and modify the data between the SEM server and the legal user. Under this environment, the goal of this paper is to prevent DoS attacks efficiently, and to protect the privacy of signers. This paper proposes Security-Mediated PKI using one-time ID. 4.1 One-time ID To prevent leakage of user’s identity and DoS attacks, Krawczyk proposed “One- time ID” [9]. One-time ID is a user’s extraordinary identity, which has two properties as follows: (1) an attacker cannot specify who is communicating even when she eavesdrops on one-time ID, and (2) One-time ID can be used only ! #"$!#" %&(')!' * +,.-0/ 1&2 354630798 +.: ;<+=/ 4 /     Fig. 2. DoS attack based on replay attack once. To realize perfect forward secrecy, Imamoto et al. proposed new method of One-time ID calculation [7]. Taking into account the computational cost of users and a SEM, we utilize one-time ID protocol with small computational complexity, like a P-SIGMA. When one-time ID is generated, this method does not require modular expo- nentiations. The user and a SEM can compute one-time ID using one-way hash function. The SEM can authenticate incoming request by checking one-time ID. Additionally, the SEM can confirm that sending request is fresh because one-time ID is used only once. Proposed system requires a shared secret key between a SEM and each user. The key-pair of a user is generated by CA, as well as the traditional SEM ap- proach. And the CA generates a shared secret key between a SEM and a user, and sends it to both a SEM and user securely. We describe the protocol of our system as follows. A user sends a request containing a message and one-time ID. One-time ID can be derived by shared secret key and be used only once. By checking one-time ID, a SEM server can confirm that requesting user is legal user. Only if requesting user is legal, a SEM generates a partial signature. Our method has the following benefits. 1. DoS-resilient A SEM can efficiently detect the attacker’s request, since an attacker can- not generate one-time ID unless she obtains a shared secret key. Moreover, proposed system can prevent replay attacks. An attacker cannot reuse the request generated by legal user because one-time ID can be used only once. 2. Efficiency One-time ID can be generated by hash computations. Therefore, computa- tion costs of a SEM and a user are more efficient, compared with traditional methods. Additionally, communications between a SEM and a user are the same as the existing Security-Mediated PKI. 3. Privacy In existing approaches, a user must send a request contained a public key certificate. Thus, an attacker can trace the user’s identity (e.g. public key certificate) by tracking user’s request. In our proposed system, an attacker cannot trace user’s identity even if she eavesdrops on one-time ID, because one-time ID is used only once. That is, our proposed system can protect the privacy of signers, compared with existing approaches. 4.2 Preliminaries (Notations) – U : user. – P K: a public key of U . – SK: a partial private key of U . – dsem : a partial private key of a SEM. – k: a shared secret key between U and a SEM. – M ACk (): Message Authentication Codes using shared key k, such as HMAC [10]. – H(): collision-resistant hash function. – OIDi : U ’s one-time ID with i-th session. – m: message. (Assumptions) 1. There is a shared secret key between the user and the SEM. 2. The secure channels are established between the CA and users, the CA and the SEM. This is the same assumption as the existing SEM approach [2, 3]. 3. Communication between the SEM and users does not have to be protected. An attacker can eavesdrop and modify the contents of request message and response message. 4.3 SEM using one-time ID (Setup) 1. As shown in Section 2.3, the CA generates P K, SK, dsem , respectively. Then the CA generates k and issues the public key certificate of U . hk, dsem i are securely communicated to the SEM and hk, SKi is communicated to U .   !"#       $&%('*)+-,/.0%'*)1  2&%'*)1-,/.0%'*)1  Fig. 3. Our proposed method 2. At first session, a SEM generates the list of OID1 and U ’s certificate. OID1 is derived as follow. OID1 = H(1, k) (Signature) 1. U makes a request using one-time ID. First, U generates OID1 and sends the following request. hM ACk (m, OID1 ), m, OID1 i 2. First, the SEM confirms that the contents of a request is fresh by using k. That is, the SEM check the MAC value M ACk (m, OID1 ). Then, the SEM checks who U is by using OID1 . If U is a legal user, the SEM validates U ’s certificate. 3. If U ’s certificate is valid, the SEM generates a partial signature P Ssem = EC(m)dsem mod n and sends the following response. Let IDsem denote SEM’s ID. hM ACk (IDsen , P SSEM , OID1 ), IDsem , P Ssem , OID1 i 4. U computes P Su = EC(m)du mod n. Then U receives above response and confirms that contents of a response is fresh by checking M ACk (P SSEM , OID1 ). m And U computes S(m) = P Ssem ∗ P Su mod n. It then verifies S(m) as a standard RSA signature. If the signature is valid, outputs it. (Update of one-time ID) 1. SEM’s update In session i, the SEM stores two one-time IDs hOIDi−1 , OIDi i for U . If one-time ID sent by U is correct, the SEM computes the partial signature and updates one-time ID as follows. OIDi+1 = H(k, OIDi ) And the SEM OIDi−1 is deleted. If connection error is occurred, U does not receive the response. In that case, U does not update one-time ID. So, the SEM stores OIDi for authenticating U . 2. U ’s update If S(m) is valid signature, U updates one-time ID as follows. OIDi+1 = H(k, OIDi ) If some error is occurred, U sends the same request once again. The SEM sends the same response. It is notice that the SEM doesn’t have to compute a partial signature again. The SEM only stores the same response. 5 Discussions 1. Signature forgery As mentioned in [2, 3], the user cannot generate signatures after being re- voked. And the SEM cannot generate signatures on behalf of the user. However, an attacker can collude with the malicious user. If an attacker compromises a SEM and learns dsem , he can create a signature by colluding with user. The existing SEM approach has the same problem. 2. DoS attacks After authenticating requests, a SEM validates a user’s certificate and gener- ates a partial signature. Suppose that an attacker can send a lot of requests to a SEM. An attacker cannot generate a legal request unless he can obtain a k. Our proposed system can prevent DoS attacks, since the SEM can detect illegal requests. 3. Replay attacks An attacker can reuse requests generated by legal users. Since one-time ID is changed for each session, an attacker cannot reuse a request for replay attacks. 4. Man-in-the-middle attack An attacker can modify the contents of request message. Suppose that U sends hOIDi , mi. An attacker modifies hOIDi , m0 i(m 6= m0 ). To prevent this attack, U sends hM ACk (m, OIDi ), m, OIDi i. Unless an attacker obtains k, an attacker cannot generate the legal request. Thus, our proposed system can prevent man-in-the-middle attacks. 5. Privacy In existing approaches, a user must send a request contained a public key certificate. Thus, an attacker can trace the user’s identity (e.g. public key certificate) by tracking user’s request. Even if the contents of the request are encrypted with k, an attacker can trace the user’s identity. This fact will be leading the privacy concerns. The privacy of signer can be protected by using SSL, but the burden of both users and the SEM may be heavy to establish the secure channel. In our proposed system, the user doesn’t have to send a request containing user’s certificate, since the SEM can specify the user by checking one-time ID. Additionally, an attacker cannot trace user’s identity even if she eavesdrops on one-time ID, because one-time ID is used only once. That is, our proposed system can protect the privacy of signers from any eavesdropper, compared with existing approaches. 5.1 Analysis of SEM’s computational costs In this section, we analyze the computational costs of the SEM. NDoS denotes the number of illegal requests sent by an attacker. Nu denotes the number of legal requests sent by legal users. P and H mean the modular exponentiation and hash computation, respectively. In the traditional SEM approach [2], the computational cost of the SEM is P (NDoS + Nu ). On the other hand, in our proposed system, the computational cost of the SEM is H(NDoS + Nu ) + P Nu . We evaluate the number of hash computations. It is assumed that P = 1000H, since H is at least 1,000 times faster to compute than P . In the tra- ditional SEM, the number of hash computations is 1000NDoS + 1000Nu . In our proposed SEM, the number of hash computations is NDoS + 1001Nu . In our proposed system, the computational costs of the SEM are more efficient than those of traditional SEM. 5.2 Other solutions There are some solutions to avoid DoS attacks based on replay attacks. This pa- per describes these methods in detail. However, these approaches cannot protect the privacy of signer. (Challenge and response) First, U sends a request message req and identifier of the user IDu to the SEM. Then the SEM responds a random number referred to as a N once. After receiving a N once, U generates a MAC using shared key k and the N once sent by the SEM. 1. U → SEM : req, IDu 2. SEM → U : N once 3. U → SEM : M ACk (m, N once), m, N once 4. SEM → U : M ACk (P Ssem , N once), P Ssem , N once 187 4th Annual PKI R&D Workshop Pre-Proceedings – Security The SEM can confirm that the request is fresh by checking N once. The SEM must store the N once. It is possible to DoS attack against SEM’s memory. – Efficiency The number of rounds is four. It is inefficient of communications, compared with those of traditional method. (Timestamp) U generates a MAC using timestamp. T S1 denotes the time of generating a request. The SEM check that T S1 is fresh. Instead of timestamp, the user can send a request containing sequence number. 1. U → SEM : M ACk (m, T S1 ), m, T S1 , IDu 2. SEM → U : M ACk (P Ssem , T S2 ), P Ssem , T S2 – Security The SEM sets a time α. Only if T ≤ T S1 +α, where T is the time of receiving request, the SEM can accept this request. – Efficiency The computational and communicational costs are the same as those of traditional method. 6 Conclusions The traditional SEM approach has the disadvantage that it is vulnerable to DoS attacks, since an attacker can send a lot of requests to the SEM server. To prevent DoS attacks, some solutions are proposed. However, these approaches cannot prevent DoS attacks. This paper proposes Security-Mediated PKI using one- time ID. Our proposed system can avoid DoS attacks with small computational complexity. Additionally, our proposed system can protect the privacy of signers, since one-time ID can be used only once. Suppose that the SEM’s partial private key dsem is compromised. If a revoked user colludes with an attacker who obtains dsem , a revoked user can generate a signature. This is the security issue in traditional SEM. Our future work is to improve this issue. References 1. K. Bicakci, and N. Baykal, “A New Design of Privilege Management Infrastructure with Binding Signature Semantics,” 1st European PKI Workshop (EuroPKI 2004), LNCS 3093, pp. 306–313, Springer-Verlag, 2004. 2. D. Boneh, X. Ding, G. Tsudik, and C. M. Wong, “A Method for Fast Revocation of Public Key Certificates and Security Capabilities,” In proceedings of the 10th USENIX Security Symposium, pp. 297–308, 2001. 3. D. Boneh, X. Ding, and G. Tsudik, “Fine-grained Control of Security Capabilities,” ACM Transactions on Internet Technology (TOIT), Volume 4, pp.60–82 , 2004 188 4th Annual PKI R&D Workshop Pre-Proceedings 4. C. Boyd, “Digital multisignatures,” Cryptography and Coding, Oxford University Press, pp. 241–246, 1989. 5. E. Bresson, O. Chevassut, and D. Pointcheval, “New Security Results on Encrypted Key Exchange,” International Workshop on Practice and Theory in Public Key Cryptography (PKC 2004), LNCS 2947, pp.145-158, 2004. 6. R. Housley, W. Polk, W. Ford, and D. Solo, “Certificate and Certificate Revocation List (CRL) Profile,” IETF RFC3280, 2002. http://www.ietf.org/rfc/rfc3280.txt 7. K. Imamoto, and K. Sakurai, “A Design of Diffie-Hellman Based Key Exchange Using One-time ID in Pre-shared Key Model,” The 18th International Conference on Advanced Information Networking and Applications (AINA 2004), pp. 327–332, 2004. 8. ITU/ISO Recommendation. X.509 Information Technology Open Systems Intercon- nection - The Directory: Authentication Frameworks, 1997. 9. H. Krawczyk, “The IKE-SIGMA Protocol,” Internet Draft, 2001. http://www.ee.technion.ac.il/ hugo/draft-krawczyk-ipsec-ike-sigma-00.txt 10. H. Krawczyk, M. Bellare, and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” IETF RFC2104, 1997. http://www.faqs.org/rfcs/rfc2104.html 11. R. Labs, “PKCS #1v2.1: RSA cryptography standard. Tech. rep.,” RSA Labora- tories, 2002. 12. K. Matsuura, and H. Imai, “Modified Aggressive Mode of Internet Key Ex- change Resistant against Denial-of-Service Attacks,” IEICE TRANS. INF.&SYST., Vol.E83-D, No.5, pp.972-979, 2000. 13. M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, “X.509 Inter- net Public Key Infrastructure Online Certificate Status Protocol-OCSP,” IETF RFC2560, 1999. http://www.ietf.org/rfc/rfc2560.txt 14. G. Vanrenen, and S. Smith, “Distributing Security-Mediated PKI,” 1st European PKI Workshop (EuroPKI 2004), LNCS 3093, pp. 218–231, Springer-Verlag, 2004. 189 4th Annual PKI R&D Workshop Pre-Proceedings On Securing the Public Health Information Network Messaging System Barry Rhodes Rajashekar Kailar Associate Director For Public Health System Development Chief Technology Officer Information Resources Management Office Business Networks International, Inc. Centers for Disease Control and Prevention www.bnetal.com www.cdc.gov Abstract The Public Health Information Network PHINMS is operating system neutral since it is Messaging System (henceforth, PHINMS) is the implemented using Java and J2EE standards. Centers for Disease Control and Prevention’s (CDC) implementation of the ebXML 2.0 Further, it provides language neutral, queue based messaging standards [EbXML]. This system was interfaces for sending and receiving messages. The developed for the purpose of secure and reliable preferred queue implementation is an messaging over the Internet. This software has ODBC/JDBC compliant database table, but been widely deployed by CDC and its public support for queues based on XML file descriptors health partners, including state and local health also exists. PHINMS supports peer-to-peer departments, and healthcare providers. PHINMS is messaging, as well as messaging via a third party designed to leverage X.509 digital certificates using a send and poll model. issued by public key infrastructures, but does not require a single, universal PKI. In this paper we Message data security is accomplished using a discuss some of the security aspects of PHINMS. combination of encryption, end-point authentication, and access control techniques. Transport reliability is accomplished using Introduction message integrity verification, transmission retries and duplicate detection on message receipt. The Public Health Information Network Since PHINMS is used to transport sensitive data Messaging System (PHINMS) is a CDC over public un-trusted networks (e.g., Internet), it developed implementation of existing standards is important to make sure that end-points trust for the secure and reliable transmittal of messages each other, are able to identify and authenticate across the Internet. each other, and that communication channels preserve data confidentiality and integrity. Further, The PHINMS relies on ebXML, XML encryption access to data sent and received should be [XMLENC], XML Digital Signature [XMLDSIG], controlled. SOAP [SOAP] and other standards. PHINMS is the primary message transport system for the The balance of this paper will focus on some of National Electronic Disease Surveillance System the security considerations that went into the [NEDSS], the Laboratory Response Network design and implementation of PHINMS. [LRN], National Health Safety Network [NHSN] and various other public health preparedness programs within CDC. By design, PHINMS is message data (payload) independent; hence it can be used to transport any type of data (e.g., text, binary). 190 4th Annual PKI R&D Workshop Pre-Proceedings Security Considerations Several security considerations went into the and trust authority may not be politically design, implementation and deployment of acceptable. In a purely PKI based authentication PHINMS. The following is a brief description: framework, a trust bridge such as the Federal Bridge CA could be used to address this problem. However, while PHINMS supports Trust1 PKI based authentication, it also supports other Secure messaging over public un-trusted modes of authentication, such as basic or custom networks requires messaging parties to be able authentication. to identify, authenticate and trust each other. For this, firstly, real world trust relationships need to PHINMS is designed to support both centralized be established between messaging organizations. and de-centralized trust models. Decisions on This may include establishing written identity binding and security credentialing are agreements on service levels, liabilities, etc., made by the deploying organizations. Decisions pursuant to OMB guidance on the Government on trusting the identity and security credentials Paperwork Elimination Act (GPEA) as well as are made mutually between messaging parties at the Electronic Signatures in Global and National the time when electronic collaborations are Commerce Act (E-SIGN). Further, business created. processes for creating and handling messages at each end of the messaging pipe need to be put in place. Once trust and business relationships are Identification, Authentication and established in real world terms, electronic Authorization collaboration agreements can be setup for message transport and processing. This includes Identification and authentication in messaging is setting up relationships to trust certification a difficult topic and is one that is far from authorities and the identity of the sending and mature. Since the message is typically sent by a receiving components (e.g., using access control process and not necessarily triggered by an lists). individual, the authentication dialog must be scriptable. That is, the sending application must be able to negotiate the exchange of credentials In a centralized trust model, a central node without human intervention. This is only performs identity binding and security possible for certain security tokens (e.g., credentialing, and all nodes establish trust hardware based one time passwords and relationships with a central node. In this case, biometric identities don’t lend themselves to this assuming n nodes, only O(n) trust relations are kind of scripted authentication exchange). needed. However, in a heterogeneous environment where trust is de-centralized, with n PHINMS supports automated authentication nodes, each node may need to establish a trust dialogs for client-certificate based authentication relationship and security credentials with every over SSL, basic authentication, and form based other node, and in the worst case scenario O(n2) authentication. The method used for mutual and trust relationships may be needed. Since automated identification and authentication messaging nodes typically belong to between messaging parties is part of the autonomous organizations and realms, electronic agreement between them, and should establishing a globally accepted central identity be established upfront, after the real world trust relationship has been established. 1 “Trust” in this context is more generic than what is involved in PKI based certificate chain validation. In particular, it may involve other (non-PKI) authentication mechanisms (e.g., basic or form based authentication). 191 4th Annual PKI R&D Workshop Pre-Proceedings Organization A Organization B PHINMS Receiver Server A PHINMS Security Credential P Sender WEB PHINMS SERVER Receiver PHINMS (PROXY) Sender Security Credential Q PHINMS Transport DMZ Receiver Queue Worker Server B Queue Firewall Internet Firewall Each messaging node in the Public Health The web-server proxies typically reside in the Information Network (PHIN) is identified by a organization’s DMZ, and mediate all inbound globally unique identifier. As shown in the traffic for the PHINMS receiver server, diagram above, a messaging node (i.e., PHINMS authenticating the sending process. SSL with sender) may contain one or more security client-certificate based authentication is the credentials that allow it to conduct automated preferred method of authentication for PHINMS, authentication dialogs with other messaging since it is a well established standard and is nodes. In the absence of a universally trusted widely implemented by web-server proxies. authority to issue security identities and credentials, potentially, a different security identity and set of credentials may be needed for Once the message sender is authenticated, it is the purpose of authenticating to each message the responsibility of the receiving organization’s destination. The security credentials may include web-server proxy to ensure that an authenticated client certificates (key-stores), passwords, etc. sender only gains access to the receiver URL. At Managing these security credentials can be a this time, PHINMS does not provide support for daunting task for the messaging administrator in attribute certificates which can be used for the face of expiring certificates, password authorization decisions. Authorization renewals etc. While certificates can be issued information is stored on the receiver server, and with an expiration period of years, passwords enforced by the web-server proxy based on the typically must be changed every 90 days, so the authenticated identity of the PHINMS senders. problem with the latter is far more daunting. Authentication Factors The recommended architecture for PHINMS For interactive authentication dialogs over the messaging is one where the PHINMS receiver Internet, generally, two factor authentication2 is components are protected from direct access considered stronger and more secure than single from the Internet, by web-server proxies as factor authentication. shown in the diagram at the top of the next column: 2 Authentication mechanisms typically use secrets such as what a user knows (e.g., password), what a user has (e.g., hardware token) and what a user is (e.g., thumbprint). These are called authentication factors. For strong authentication, a combination of two of these three factors is used. 192 4th Annual PKI R&D Workshop Pre-Proceedings However, in the case of B2B automated In the case of store and forward messaging, data security dialog, the security value of two- is protected from being read by intermediaries factor authentication is significantly by using asymmetric encryption using the public diminished, since there is no real user key of the message recipient to encrypt a random symmetric key, which in turn encrypts behind the authentication dialog. All user the data. Additionally, communication is factors required for the authentication typically conducted over a Secure Sockets Layer dialogs would need to be pre-configured into (SSL) channel, ensuring that the message meta- the software that initiates the authentication data is also protected. To ensure end-to-end handshake. Further, at the time of this confidentiality, the channel between the web- writing, there are no published and accepted server proxy and the application server is also Internet standards for two factor over SSL. authentication in B2B transactions. While it is possible to use hardware based security modules (sometimes called HSM) to Integrity and Non-repudiation emulate additional authentication factors for PHINMS supports the use of XML digital B2B exchanges, such mechanisms require signatures [XMLDSIG] for message integrity additional hardware and management and non-repudiation of message data. Signing complexity. certificates can be sent as part of the signature meta-data facilitating verification of the signature, alternatively, signing certificates can Confidentiality be statically pre-configured at the receiving Since communication is over un-trusted public node. Additionally, communication is typically networks, protecting its confidentiality is conducted over SSL with client-certificate based important. PHINMS uses payload level authentication, which provides further message asymmetric encryption for end-to-end persistent integrity and non-repudiation assurances. confidentiality. The XML encryption standard The XML encryption standard [XMLENC] is used for encrypting the payload. 193 4th Annual PKI R&D Workshop Pre-Proceedings Access Control The ebXML messaging Message Message standard supports message Sending Service=X Application Receiving labels called “Service” and Application Action=Y In-Queue A Application A “Action”. These XML tags are part of the message envelope, and can be mapped to a Out-Queue service on the receiving node. Message Message PHINMS Service=P Application Receiving Receiver PHINMS (Service=X, Action=Q In-Queue B Application B In the PHINMS Action=Y) Sender implementation, messages that are received using the receiver server are stored in database tables (queues) based on their Service and Action tags. These Message queues are the equivalent of an Service=M Application Receiving application “inbox”, and each Action=N In-Queue C Application C application can only access its own inbox. Public Key Infrastructure (PKI) Firewalls PHINMS is designed to leverage a PKI, but it does not require a universal PKI. For instance, a Though firewalls are necessary for the PHINMS sending client can use a client protection of resources within an enterprise, they certificate issued by one certification authority complicate matters for a messaging system (CA) to authenticate itself to a PHINMS receiver trying to send messages across enterprise server, and use a client certificate issued by a boundaries. PHINMS uses two independent different CA to authenticate itself to a different pieces of code, a client capable of sending PHINMS receiver server. Currently, PKI trust messages and receiving real time (synchronous) relations are statically defined at the time when responses, and a server receiver that can receive collaboration is established and configured messages at any time. These two components between messaging entities. This is sometimes may be used in three possible scenarios. These called the “Certificate Trust List” model. examples assume that the parties are in different organizations with separate firewalls. Ideally, public key certificates are published in 1. Both parties are located outside their an LDAP directory (need not be centralized), but respective firewalls (i.e., in their DMZ) PHINMS also supports a web-service interface 2. One party is outside the firewall and the to publish and retrieve certificates. As a third other is inside a firewall. alternative, encryption public key certificates 3. Both parties are inside their respective can be distributed out of band and pre- firewalls. configured at the message sending nodes. Public key certificates can be published in de- centralized LDAP directories as well. 194 4th Annual PKI R&D Workshop Pre-Proceedings In the case where both parties are located the server can return the file as a response to the outside their respective firewalls, messages may send. Because the client is not really receiving be sent and received at any time and messages, the complexity of the software is acknowledgements send either synchronously or reduced and therefore the platform requirements asynchronously. This requires that both parties are reduced as well. have sending and receiving components installed. Typically the client can reside on a workstation capable of hosting a Java application. Firewall DMZ DMZ Firewall Intermediate Party Send Firewall PHINMS DMZ PHINMS PHINMS Send Send/Poll Send/Poll DMZ DMZ Firewall Intranet Intranet PHINMS PHINMS Scenario 1: Both parties are Internet accessible (i.e., in DMZ) Firewall Scenario 3: Both parties behind firewalls For the situation where one party is behind a firewall and the other party has a server receiver In the case where both parties are behind located in the public Internet space, message firewalls, a third party server with Internet sending options are slightly reduced. The client presence is required to broker the exchange. For piece behind the firewall can send data much example let’s say party A is located behind a like a typical browser to a receiver and receive firewall in enterprise 1 and A wants to send a synchronous acknowledgements back. message to party B in enterprise 2, where B is also behind a firewall. Then A must send a Because it sits behind a firewall, the client message to an intermediary server on the cannot receive messages as firewalls typically Internet with a service action that states that the block this type of “push” of information. What server should hold the message in a queue for B. it can do is poll for messages. Then when B polls the server, it will find the message from A in its queue and request it. Intranet DMZ DMZ Intranet Authentication Interoperability Poll The ebXML messaging standard specifies the PHINMS PHINMS structure and semantics of message meta-data and addressing information, but for the most Send part, leaves the messaging security (identification and authentication) aspects to the Firewall Firewall implementers. Scenario 2: One party is behind firewall Basically a poll is where a client sends a message to a server with some meta-data which maps to a piece of functionality that looks to see if the server has something for the client. If so, 195 4th Annual PKI R&D Workshop Pre-Proceedings When used, XML digital signatures should be ebXML Interoperable ebXML combined with a handshaking protocol such as Implementation P Implementation Q SSL, which mitigates the threat of replay attacks Security Security Mechanism A Non-Interoperable Mechanism B and provides freshness assurances. The alternative is to use SSL with client certificate Messaging not interoperable based authentication. This provides per-link assurance of identity and authentication, as well ebXML Interoperable ebXML as confidentiality. Since SSL is the most widely Implementation P Implementation Q accepted standard, this is the recommended Security Interoperable Security mode of authentication for PHINMS. Mechanism C Mechanism B Messaging interoperable Acknowledgements The authors would like to thank the Public As shown in the above diagram, for Health Information Network Messaging System interoperability, in addition to the message team: Michele Bowman, Thomas Brinks, structure and semantics, the security Dongtao Jiang, Vaughn McMullin, Thomas mechanisms also need to interoperate. XML Russell, and John Thomas. digital signatures can be used to support message non-repudiation (the strength of which is dependent upon legal elements that Summary transcend the technology), but using them may not be sufficient for the purpose of The security design, implementation and authenticating clients to sensitive deployment considerations of CDC’s Public Health Information Network Messaging System applications unless its freshness is (PHINMS) were discussed herein. established. Without adequate freshness assurances use of DSIG in authentication may not be adequate for some applications. 196 4th Annual PKI R&D Workshop Pre-Proceedings References [EbXML] Message Service Specification [NHSN] National Healthcare Safety Network (NHSN)(http://www.cdc.gov/ncidod/hip/NNIS/mem Version 2.0, OASIS ebXML Messaging Services bers/nhsn.htm ) Technical Committee (http://www.ebxml.org/specs/ebMS2.pdf) [SOAP] SOAP Version 1.2 Part 0: Primer [LRN] The Laboratory Response Network Partners (http://www.w3.org/TR/2003/REC-soap12-part0- in Preparedness http://www.bt.cdc.gov/lrn/ 20030624/ ) [NEDSS] National Electronic Disease Surveillance [XMLENC] XML Encryption Requirements System, The Surveillance and Monitoring (www.w3.org/TR/xml-encryption-req) Component for the Public Health Information Network. (www.cdc.gov/nedss/) [XMLDSIG] XML-Signature Syntax Processing (www.w3g.org/TR/xmldsig-code 197 4th Annual PKI R&D Workshop Summary Ben Chinowsky, Internet2 Note: this summary is organized topically rather than chronologically. See http://middleware.internet2.edu/pki05/proceedings/ for the workshop program, with links to papers and presentations. The overarching theme of this fourth iteration of the PKI R&D workshop was putting PKI to use. There was much experience to report from new and ongoing PKI deployments. Deployments One of the largest PKI projects is the ongoing Department of Defense deployment; Rebecca Nielsen brought the group up to date on DoD's experiences. Nielsen noted that PKI cycle times are around 72 months, while hardware cycle times are more like 24 months, so you end up running on obsolete hardware much of the time. Also, while "smartcards are good," reissuance is hard when you have 3.5 million users. Organizational issues loom larger than technical ones; getting buy-in from both users and management is particularly challenging. Secure web server access is the primary application, though signing and encrypting email are also done; user education is a particular challenge with the latter ("this PKI thing is a problem because I can't sign my boss's emails anymore.") Nielsen characterized the DoD rollout as "generally successful." Rajashekar Kailar presented experiences with Securing the Public Health Information Network Messaging System (PHINMS), deployed by CDC and its partners. PHINMS uses certificates for SSL but does not require a specific source, and Kailar noted that other means of secure authenticated transport could also be acceptable. Kailar identified this as a key lesson learned: where multiple credentials and mechanisms for security are acceptable, permit them, rather than trying to impose just one. The PHINMS presentation was followed by a panel on PKI In Healthcare. Richard Guida presented an overview of the sector, noting that it can be divided up into four categories: companies that supply medical devices, equipment and pharmaceuticals; "points of care" (e.g. hospitals and clinics); companies that handle payments and billings (e.g. insurers); and companies or institutions that support or perform medical research, including clinical trials. Guida noted that while the strong focus on patient care at the points of care tends to lead to less of a focus on security, there is lots of growth in this sector, and lots more the research community and vendor community can do to help ensure that privacy requirements set forth under the Health Insurance Portability and Accountability Act (HIPAA) are met. Reducing the burden of paperwork, especially the burden of storing paper and moving paper around, is a particularly great need; reducing the paperwork involved in clinical trials can save time without reducing the quality of the trials. Guida cited Acrobat 6 and 7 as "exemplars" of PKI growing up. Terry Zagar discussed the biopharmaceutical industry's Secure Access For Everyone initiative (SAFE; http://www.safe-biopharma.org/). Zagar noted that PKI is much harder to scale between enterprises than within them, hence the need for common standards such as those being developed by SAFE. Many companies already have PKIs and want them to interoperate so that certificates can be accepted by outside parties; minimizing the need for reinvention is a major consideration. SAFE has embraced the use of a bridge CA as a means to this end. SAFE plans to have tens of thousands of certificates issued to doctors and other healthcare professionals by the end of the year, and hundreds of thousands by next year. John Landwehr offered details on the Acrobat signing technology cited by Guida and intended for use by SAFE to execute and validate legally binding digital signatures that comply with regulatory requirements (FDA 21 CFR Part 11). Documents let you apply signatures inline — applying the principle of making it as much like paper as possible — and can specify parameters for allowed signatures. The technology has passed the 250+ tests in the NIST PKI test suite and is JITC certified; a FIPS 201 evaluation is underway. In the discussion, Ken Klingenstein pointed out that the communities that seem to have the most traction in implementing role-based access control are those that have regulatory mandates that lead to common definitions of roles — above all the securities industry. The panelists agreed on the need for RBAC in healthcare, though this is a ways off yet. Guida noted that there are recurring problems with large institutions failing to understand rapid technical changes and accompanying opportunities; having real-world success stories to tell helps a lot in this regard. Landwehr noted that the standardization of smartcards has the potential to make cert deployment a lot easier, and Zagar stressed the importance of avoiding US-centric standards. Mike Just discussed Canada's Secure Delivery of E-Government Services, updating the group on work presented at PKI03. EPass is now a successfully established solution; the current issues are political and legal, e.g. privacy concerns leading to multiple and burdensome enrollments. Just also noted that Canadian law has recently changed to make electronic data acceptable as legal evidence. A WIP session by Jeroen Van de Graaf provided an overview of PKI Projects in Brazil. As in the US, projects are underway at the national government and pan-Higher-Education levels. There is also a large project in the state of Minas Gerais, driven by the need to fix the presently fraud-prone process of publishing legal judgments in newspapers. The long-term goal is to issue smartcards and certs for all 15 million residents of the state. At all levels, there is a strong bias in favor of open-source solutions, for both financial and strategic reasons. Van de Graaf also noted that a 2001 federal directive gave digital signatures the same legal status as wet signatures. There were also two sessions on bridge deployments and PKI interoperability. Peter Alterman surveyed International and Bridge-to-Bridge Interoperability, including pending cross-certifications between FBCA and Canada, FBCA and Australia, and the DoD PKI and trusted allies. Alterman noted that where PKI-PKI cross-certification is concerned primarily with policies, bridge-bridge cross-certification requires that business practices be commensurate as well. Scott Rea followed with an update on HEBCA and Phase 4 of the PKI Interoperability Project. HEBCA grew out of the NIH-EDUCAUSE PKI interoperability pilot, and has since been moved to Dartmouth; production FBCA/HEBCA cross-certification is expected in a few months. Form-signing is the principal application. A perspective on Side-Effects of Cross-Certification was provided by James Fisher: "It is easy to structure unintended and difficult-to-detect consequences." This assertion is amply documented in Fisher's paper and slides. In the Q&A for this session, Fisher noted that the technical aspect of bridging is relatively straightforward; it's getting the trust path to reflect what was agreed on in human-to-human trust negotiations that introduces most of the complexity. The deployment-experience portion of the workshop was rounded out by Ken Klingenstein's survey of Interfederation Interoperability, E-Authentication and Shibboleth. There are now production federations in several countries, and many campuses and other enterprises which are themselves federal in structure have been creating federations for themselves. Indemnification issues are the biggest obstacle in getting universities to participate in federations. Klingenstein noted that SAML 2.0, ratified by OASIS earlier this year, is likely to prove a high plateau; it's "a fusion product" with Liberty Alliance, which has incorporated most of its functionality into SAML and is moving off in new directions. Addressing recurring deployment issues Of the presentations not concerned with specific deployments, many considered developments aimed at solving problems that recur across deployments. Note that in addition to the presentations discussed below, the proceedings include papers in this area from two contributors — Tice DeYoung and Karl Scheibelhofer — who ended up not being able to attend the workshop. One of the most important areas of cross-deployment development is, of course, standards. With respect to IETF, PKIX co-chair Tim Polk noted that no longer is everything happening in PKIX; there are also important developments in PKI4IPSEC and LTANS. Internationalizing domain names is a major focus, and a new version of RFC 3280 with expanded support for this is expected later this year. Overall, Polk characterized the core PKI specs as stable and the supplemental specs as ready for implementation, so standards obstacles to PKI deployment are diminishing. IETF Security Area Director Russ Housley noted the creation of the ENROLL working group; it's likely that considerable research will be needed to create an effective standard in this area. Eric Norman asked if IETF is planning to issue standards for digital signatures, given that the courts are likely to decide what's acceptable here. There was general agreement that the technical community — primarily in IETF, but also in government bodies like NARA — still needs to take the lead in guiding implementations. Housley said that social- engineering attacks based on flaws in Unicode are likely to remain a problem for some time; several working groups are studying the complex tradeoffs in this area. Polk also surveyed the FIPS 201 project at NIST. This is a Presidentially-mandated standard for both physical and electronic access to Federal facilities; public-key cryptography and contactless smartcards are the core technologies. FIPS 201 was published in February of this year. Biometrics introduce new vulnerabilities and can compromise privacy; fingerprint images are big and therefore slow to move on and off cards. Cards were chosen over other hardware such as dongles largely because they can function as old-fashioned photo IDs as well. See http://csrc.nist.gov/piv-project/ for more on FIPS 201. David Engberg of CoreStreet presented work on Secure Access Control with Government Contactless Cards, for FIPS 201 in particular. Engberg noted a prosaic reason for contactless cards: the contact strips on swipe cards tend to wear out after a few months. On the other hand, there are privacy risks in allowing remote access to contactless cards. Engberg also noted that processing-power limitations on PKI are "starting to melt away." Jon Callas discussed a hybrid approach to IBE with conventional PKI. IBE as first proposed by Shamir requires a master secret on a central server, creating Kerberos-like vulnerabilities. Callas's approach addresses this by removing offline key generation; this system has also been referred to as "attribute-based enrollment". Callas noted that when you have ubiquitous devices that are hard to turn off — as is increasingly the case just about everywhere — the advantages of offline operations are minimal anyway. Callas argued that his hybrid approach can bring the advantages of IBE to existing PKIs. Marco "Kiko" Carnut presented an IBE-like approach to Taking Cryptography Out of the Browsers. This is accomplished by a proxy, called Kapanga, that takes over functions like certificate issuing and webform signing that are often handled badly by browsers. Carnut described his approach as similar to that of Callas's "Self-Assembling PKI" as presented at PKI03: make every application an opportunity for enrollment. Carnut further elaborated his ideas in a WIP session, offering an IBE-like idea for instantaneous enrollment. In this approach, certs are issued with no authentication, and trust depends on the client CA instead of the root. Sang Seok Lim presented a method of improving access to cert repositories via LDAP component matching. He noted that while component matching is generally considered to be the approach of choice, it's complex; his work demonstrates that the complexity can be limited enough to ensure deployability. There were two presentations on delegation of authority. David Chadwick described a Delegation Issuing Service for X.509. Advantages of this approach include the managers doing the delegating not needing to have certificates themselves. Chadwick noted that the lack of standard terminology for roles is a big obstacle to any delegation scheme, including this one. Liang Fang presented XPOLA, which stands for eXtensible Principle Of Least Authority. XPOLA is motivated by the need to reduce the time needed to get access to Grid services and by the need to improve authorization scalability and fine-grainedness. Kenji Imamoto offered One-time ID as a solution to DoS attacks on the SEM approach to revocation. One-time ID makes use of symmetric key authentication to provide low overhead. Two talks explored proposed extensions to the Shibboleth federating software. David Chadwick discussed Adding Distributed Trust Management to Shibboleth by combining it with PERMIS (PrivilEge and Role Management Infrastructure Standards; see http://www.permis.org/). Chadwick's paper explores several different ways to combine the two. Von Welch described Integrating Shibboleth and Globus. The motivation for this work is to get virtual organizations of scientific researchers out of the business of IT support. Integration is based on replacing Shibboleth's handle-based authentication with X.509, offering stronger security while leveraging the X.509 installed base. Working code is expected this summer; see http://grid.ncsa.uiuc.edu/GridShib/. In a WIP session, Carl Ellison discussed the need for ceremony analysis — formal analysis of the human-to-human, out-of-band elements of security processes. Ellison argued that these elements are just as much part of security protocols as are operations that take place inside computers, and need to be taken seriously as such. BoF on Human-Computer Interaction More generally, it is widely agreed that human-computer interaction (HCI) is one of the areas where much work is still needed if PKI deployments are to thrive. HCI was the main focus at PKI03; an HCI BoF at PKI05 reviewed recent developments in this area. BoF chair Eric Norman has been trying to identify the minimum set of things a PKI user should need to learn, and used a draft list to get discussion started. The consensus from his previous discussion on the HCISec list (see http://groups.yahoo.com/group/hcisec/) is that this list needs to be much, much shorter. The BoF participants concurred in this judgment; Paul Danik asked "How do you teach someone with rudimentary computer skills even one of the things on Eric's list?" The group discussed Simson Garfinkel's work on HCI (see http://simson.net/). Sean Smith was a guinea pig for Garfinkel's prototype, which he found confusing — "why are these things changing colors?" — although as several people pointed out, Smith might not be the best test subject for a system aimed at the naive user. There was general agreement that it's well worth paying attention to Garfinkel's criticisms of existing PKI user interfaces. Smith noted that it's only in the last couple of years that phishing and IDN attacks have created broad awareness that spoofing is really a problem, and recommended taking a look at the presentations from the DIMACS Workshop on Theft in E-Commerce: http://dimacs.rutgers.edu/Workshops/Intellectual/slides/slides.html. He also pointed the group to anti-spoofing work presented at Usenix: http://www.cs.dartmouth.edu/~sws/abstracts/ys02.shtml. The BoF participants discussed several other factors involved in making PKI usable. Carl Ellison stressed the importance of giving the relying party control over what name is used for a trusted entity, as all other information the user learns about that entity is linked to the name; this is an entrenched human behavior that no amount of "user education" can or should try to change. Jon Callas observed that "one of the principles of real human factors is, the user is always right." Callas also related an experience with certs expiring mid-transaction; there was general agreement that "about to expire" warnings are needed. Several of those present spoke well of The Design of Everyday Things by Don Norman (no relation to Eric); though the book is more about doors and clock radios than computers, its principles apply to making anything more usable. Farther out There were also several talks aimed at solving broader problems with PKI, or at applying it in new ways. Of these, the one with the widest implications was Arjen Lenstra's discussion of Progress in Hashing Cryptanalysis. Lenstra discussed the implications of recent discoveries of weaknesses in commonly-used hash functions; his slides offer an overview of the mathematics involved, and of how these weaknesses might be exploited in real-world attacks. This February NIST announced that SHA1 should still be considered secure until it's phased out around 2010. Lenstra's assessment is somewhat more pessimistic; while there are currently no dangerous attacks based on these recent discoveries, research continues, and such attacks are likely to emerge soon. Lenstra suggests abandoning SHA1 for SHA256 and launching a competition for a replacement for the entire SHA family. On the other hand, Bill Burr noted that encouraging a move to SHA256 in the short term could make it a lot harder to move to the hoped-for SHA replacement in the medium term. NIST doesn't have the resources to develop that replacement. Burr agreed that a global competition is the best way to mobilize the resources needed. Cliff Neuman presented a WIP session on work by his student Ho Chung on a multidimensional approach to Modeling Strength of Security. This work is at an early stage. A. Prasad Sistla described a scheme for Language-Based Policy Analysis in a SPKI Trust Management System, using modal logic to describe roles in SPKI. While citing related work, Sistla claims that this is the first general policy- analysis language, usable e.g. with Keynote or XACML. There is no implementation yet. Terence Spies discussed Pairing Standards for Identity Based Encryption. "Pairings" are a new elliptic-curve crypto primitive. An IEEE study group on pairings and their application to IBE is just getting underway; see http://grouper.ieee.org/groups/1363/WorkingGroup/. Finally, Meiyuan Zhao presented her simulations aimed at Evaluating the Performance Impact of PKI on BGP Security. Russ Housley stressed the importance of this work; he noted that securing BGP is one of his top priorities as an IETF Security Area Director. Housley also observed that memory requirements are a major obstacle to S-BGP deployment, and suggested focusing future research on approaches that require less memory, in particular by using elliptic-curve cryptography. Conclusions The PKI0x series has clearly matured, as demonstrated by its emulation in Europe and Asia (see "Related Workshops" at http://middleware.internet2.edu/pki05/), by this year's conference having the largest number of accepted papers yet, and by several of the sessions offering followups on ongoing work presented in previous years. PKI04 produced consensus on two main ideas: "Understanding and educating users is centrally important" and "The specifics of any particular PKI deployment should be driven by real needs, and should be only as heavyweight as necessary." PKI05 reaffirmed this consensus; it also demonstrated that we are much further along in applying the latter principle than the former. There was strong general agreement on keeping the workshop's mix of research and deployment topics. Please join us for PKI06 (http://middleware.internet2.edu/pki06/), April 4-6, 2006. Adding Distributed Trust Management to Shibboleth David Chadwick, Sassa Otenko, Wensheng Xu University of Kent, Computing Laboratory, Canterbury, England, CT2 7NF each Shibboleth target resource site trusts Abstract each Shibboleth origin (home) site in the This paper analyses the simplicity of the federation, so that whatever assertions – trust model adopted by the Shibboleth authentication or authorisation – are infrastructure and describes an enhanced digitally signed by the origin site, they will distributed trust model and authorisation be believed and trusted by the target site. decision making capability that can be There is little scope for differentiation implemented by using X.509 attribute between authentication authorities and certificates and a Privilege Management attribute authorities, or for allowing more Infrastructure such as PERMIS. Several sophisticated distribution of trust, such as different combinatorial approaches can be static or dynamic delegation of authority. taken, depending upon the trust models adopted by the Shibboleth target and origin Another limitation of the Shibboleth sites, and each of these are described. The infrastructure is that it only provides a basic paper also discusses whether user privacy, access control decision making capability. which is strongly protected by Shibboleth, is Whilst this is adequate for many use cases, it bound to be weakened by the use of X.509 lacks the flexibility and sophistication attribute certificates rather than simple needed by many applications, for example, attributes, and concludes that this does not to make access control decisions based on have to be the case. role hierarchies or various constraints such as the time of day or separation of duties. 1. Introduction We realised that both these limitations could Shibboleth [1] is a distributed web resource be addressed by integrating an X.509 access control system that allows federations Attribute Certificate (AC) Privilege to co-operate together to share web based Management Infrastructure (PMI) [3] with resources. It has done this by defining a Shibboleth. PERMIS [2] is one such protocol for carrying authentication infrastructure that has already been information and user attributes from a home successfully integrated into Grid application site to a resource site. The resource site can target sites [4] to support the distributed then use the attributes to make access management of trust. PERMIS incorporates control decisions about the user. The a sophisticated policy controlled RBAC Shibboleth project is run by the Internet2 access control decision engine (also called a consortium in the USA, and universities policy decision point (PDP)). The PERMIS throughout the USA and Europe (at least) PMI has been used to implement distributed are now starting to build experimental trust management in Shibboleth. services based upon it. The rest of this paper is structured as At the heart of Shibboleth is a trust model follows. Section 2 provides an overview of that allows the members of a federation to Shibboleth. Section 3 introduces the more cooperate together. This trust model, whilst sophisticated distributed trust model that we functional, is somewhat limited. Basically wanted to introduce into Shibboleth. Section authenticate its users properly. This is 4 describes how the trust model can be facilitated by the exchange of public key implemented using an X.509 PMI such as certificates or the use of a common trusted PERMIS. Section 5 describes the different root Certification Authority. In the latter combinations of X.509 ACs, attributes, and case both sites will have been issued with a the PERMIS PDP that may be integrated certificate by the root CA (or one of its with Shibboleth to provide the desired trust subordinates). When a digitally signed models of the Shibboleth target and origin SAML message1 arrives from the home site, sites. Section 6 discusses user privacy such as one containing a user handle, this issues and section 7 discusses revocation can be validated and trusted by the resource and performance issues that arise with using site. X.509 ACs. Finally Section 8 concludes. After the user has picked his/her home site, 2. Overview of Shibboleth their browser is redirected to their site’s Shibboleth is a web based middleware layer authentication server and the user is invited that currently makes use of SAMLv1.1 [5] to log in. If a user is untrustworthy and tries for encoding some of its messages. When a to fool the system by picking a home site to user contacts a Shibboleth resource site from which they do not belong, they will have their browser, requesting access to a difficulty authenticating themselves to that particular URL, Shibboleth single sign on site’s authentication server, since they won’t and access control takes place in two stages: have any valid credentials. However, if they – In stage one the resource site pick their own home site, they should find redirects the user to their home site, authentication is no problem. After and obtains a handle for the user that successful authentication, the home site re- is authenticated by the home site directs the user back to the resource site and – In stage two, the resource site returns the message carries a digitally signed SAML the handle to the attribute authority authentication assertion message from the of the home site and is returned a set home site, asserting that the user has been of attributes of the user, upon which successfully authenticated by a particular to make an access control decision. means e.g. username/password, Kerberos or In a large distributed open environment digital signature. The actual mechanism stage one has a number of complications. used is local to the home site, and the Firstly how does the resource site know resource site simply has to have a prior where the user’s home site is? Secondly, agreement with the home site which how can the resource site trust the handle authentication mechanism(s) will be trusted. that is returned? The answer to these two If the digital signature on the SAML questions is surprisingly simple, and is part of the Shibboleth trust model. When the user 1 Note that the connection from the origin server to first attempts to access a resource site, the target server can also be optionally protected by he/she is redirected to a Where Are You SSL in Shibboleth, but this is used to provide From? (WAYF) server, that simply asks the confidentiality of the connection rather than message user to pick his/her home site from a list of origin authentication. In many cases a confidential SSL connection between the origin and the target will known and trusted home (Shibboleth origin) not be required, since the handle is obscure enough to sites. The target site already has a pre- stop an intruder from finding anything out about the established trust relationship with each user, whilst the SAML signature makes the message home site, and trusts the home site to exchange authentic. authentication assertion verifies OK, then have some say over the contents of their the resource site has a trusted message attribute release policies. This is to minimise providing it with a temporary pseudonym the loss of a user’s privacy. for the user (the handle), the location of the attribute authority at the origin site and the 3. An Enhanced Trust Model for resource URL that the user was previously Shibboleth trying to access. The resource site then As can be seen from the above overview of returns the handle to the home site’s Shibboleth, its trust model is sound although attribute authority in a SAML attribute rather limited. The model is that the target query message and is returned a signed site trusts the origin site to authenticate its SAML attribute assertion message. The users and to manage their attributes correctly Shibboleth trust model is that the target site whilst the origin site trusts the target site to trusts the origin site to manage each user’s provide services to its users. The trust is attributes correctly, in whatever way it conveyed using digitally signed SAML wishes. So the returned SAML attribute messages using target and origin server assertion message, digitally signed by the X.509 key pairs/certificates, configured into origin, provides proof to the target that the the Shibboleth software by their filenames. authenticated user does have these attributes. (Note that the private key files were held This message exchange should be protected unencrypted in the Shibboleth software we by SSL if confidentiality/privacy of the were using, so this is a weakness in the returned attributes is required. The attributes implementation if not actually in the trust in this assertion may then be used to model.) As each site will typically only have authorise the user to access particular areas one key pair per Shibboleth system, from of the resource site, without the resource site the recipient’s perspective, there is only a ever being told the user’s identity. single point of trust per sending Shibboleth system. Although it is not difficult to The latest version of the Shibboleth configure multiple roots of trust into a specification has introduced a performance Shibboleth target site – it is, in fact, a matter improvement over the earlier versions, by of updating one XML file only – the issue is optionally allowing stage one and stage two one of being able to use a finer grained to be combined together, in that the initial distributed trust model, and of being able to digitally signed SAML message may use multiple origin site authorities (and optionally contain the user’s attributes as private keys) to issue and sign the well as the authentication assertion. It is authentication and attribute assertions. expected that the Shibboleth software will be upgraded to this during 2005. In many origin sites a single back end LDAP server is the sole authoritative source Shibboleth has two mechanisms to ensure for both authentication and attribute user privacy. Firstly it allows a different information. Typically Shibboleth sites pseudonym for the user’s identity (the implement stage one by issuing a Bind handle) to be returned each time, and operation on their LDAP server, using the secondly it requires that the attribute username and password provided by the user authorities provide some form of control to the web login prompt. If the Bind over the release of user attributes to resource succeeds, the user has been successfully sites, which they term an attribute release authenticated against the password stored in policy. Both users and administrators should the LDAP server. Stage two is implemented by searching the LDAP server for the project leader attribute to an employee attributes stored in the user’s entry, and under his control. filtering these against the Shibboleth - The target should be able to state, in its origin’s attribute release policy before policy, which of the attribute authorities returning them to the Shibboleth target site it trusts to issue which attributes to as signed SAML attribute assertions. One which groups of users. The target site can see that in such an implementation, and should be able to decide independently as a consequence of the Shibboleth trust of the issuing site which attributes and model, the Shibboleth target site has no authorities to trust when making its choice but to make access control decisions access control decisions. based on these attributes, without knowing - Not all attribute issuing authorities need who actually issued them to the user, be part of the origin site. A target site whether they are still valid or not, or should be able to allow a user to gain whether they are even the correct attributes access to its resources if it has attributes for the particular user, since the user’s name issued by multiple authorities, for is not provided to the target site for privacy example, a target site holding statistics reasons. The Shibboleth origin doesn’t trust on medical data may require a user to anyone to see the attributes except the have an attribute issued by a medical trusted targets, but even they are not allowed authority as well as one issued by the to see the binding between the attributes and university that employs the user as a the owner’s identity. (The two reasons given researcher. for this in the Shibboleth documentation are - The trust infrastructure should support user privacy and legal requirements for dynamic delegation of authority, so that universities to protect a student’s privacy). a holder of a privilege attribute may The target site thus has no option but to delegate (a subset of) this to another indirectly trust the contents of the origin person without having to reconfigure site’s LDAP server or other attribute anything in the system. For example, a repository, since it trusts the origin site project leader may wish to assign a role directly. One can further see that the origin of team leader to one of his team site has to strongly protect the attributes in members; he should be enabled to do its (LDAP) repository, which means that it is this dynamically by the infrastructure probably restricted to centrally without having to reconfigure the administering these, and so would prefer system. The target site should be able, in that they do not change that often. turn, to state in its policy whether it Flexibility and distributed management of trusts these delegated attributes or not, the attributes is hard to adopt. Dynamic regardless of the delegation policy at the delegation of authority would be even harder user’s site. to support. - The target site should be able to decide if it really does trust the origin’s attribute We propose that an enhanced trust model repository (e.g. LDAP server), and if should have the following features. not, be able to demand a stronger proof - Multiple authorities should be able to of attribute entitlement than that issue attributes to the users, and the conferred by a SAML signature from the target site should be able to verify the sending Web server. issuer/user bindings. For example, a - Finally, the origin site, if it chooses, manager should be able to assign a should be able to use a Privilege Management Infrastructure, rather than a repository or the underlying transport strongly protected attribute repository, mechanism used to convey them, since it for allocating attributes to its users. This can directly validate the digital signatures on will allow the origin to distribute the the attribute certificates when it receives management of attributes throughout its them2. Furthermore, if the target site’s PDP site. Nevertheless, the origin site should policy is willing to allow dynamic still be able to communicate with delegation of authority, the PDP can check Shibboleth targets as usual by only the attribute certificate chain to ensure that sending attributes to them, if the targets all ACs were properly authorised by their are happy to trust these. issuing authorities. By using ACs in its authorisation decision making, rather than 4. Implementing the Enhanced plain attributes, a target site can support Trust Model using an X.509 PMI much more sophisticated and finer grained X.509 attribute certificates (ACs) provide a access control policies, for example, by convenient, standardised and compact requiring a user to have ACs issued by representation of attribute assignments, and multiple authorities, from different issuing satisfy several of the above requirements. domains, before they are granted access to The basic X.509 attribute certificate particular resources. construct comprises: the name of the holder of the attributes, the name of the issuing The PERMIS X.509 PMI is part of the US authority, the set of attributes, and the time NSF Middleware Initiative software release. that they are valid for. An extension field PERMIS provides a policy controlled role can optionally be inserted to state that the based access control (RBAC) infrastructure, holder is allowed to dynamically delegate (a in which the user’s roles are stored in X.509 subset of) these attributes to another user, ACs. These ACs are either passed to the and the depth to which delegation can take PERMIS PDP along with the user’s place. The whole AC construct is digitally requested action (the push model), or can be signed by the issuer (attribute authority), fetched from one or more LDAP servers by thus providing integrity control and tamper the PDP (the pull model). The PERMIS resistance. Multiple attribute authorities can PDP then returns a granted or denied co-exist, either in a hierarchical relationship response according to the policy in force at or as separate independent authorities. that time. The PERMIS policy is written in Attribute certificates are typically long lived, XML, and is in many respects a simplified and after issuance, the ACs need to be stored alternative to XACML [6], although the somewhere for retrieval by the target’s PERMIS policy supports dynamic policy decision point (PDP), and LDAP delegation of authority, unlike XACML. repositories at the AA site are a natural The XML policy is itself stored in an X.509 choice for this, although web servers, attribute certificate, and is digitally signed filestores and other repositories can also be by the trusted authority in control of a target used. resource. This policy certificate is the root of 2 It is the case with ACs that the holder’s identity is If the ACs are stored in the AA site’s LDAP revealed in the Holder field of the AC. But the directory or other repository, and transferred Holder field could still be an opaque string, from there to the target site’s PDP by understood by the Issuer at the Origin, and it doesn’t Shibboleth, then the target site’s PDP does have to be understood by the AC verifier at the not need to indirectly trust the attribute Target site. See section 6 for a fuller discussion of this issue. trust for the access control decision making. current roles/attributes is allowed to access a When the PERMIS PDP is initialised, it is particular target resource, it consults the given the name of the trusted authority, and TAP and returns granted or denied based on the ID of the policy to use (each policy has a its contents and the current state of the globally unique identifier). PERMIS reads in environment (time of day, resource usage the policy certificates from the authority’s etc.). LDAP entry, checks their signatures, and keeps the one with the correct ID. It now has Because PERMIS can act in either push or the correct trusted policy with which to pull mode with attribute certificates, then it make access control decisions. PERMIS is possible for a target site to create a policy thus forms a good basis for demonstrating that requires a user to have attributes issued the distributed management of trust with by multiple different authorities in different Shibboleth. domains, and the PERMIS PDP can then pull these at authorisation time regardless of 4.1 The PERMIS PDP Policy the origin site that the user has actually The PERMIS policy contains a list of trusted authenticated to. attribute authorities, the set of attributes they are trusted to assign, and the groups of users 5. Supporting the different trust they can be assigned to. This is called the models of Shibboleth sites role allocation sub-policy (RAP). Attribute One can immediately see that if Shibboleth authorities can be distributed worldwide, and PERMIS are integrated together, then and can be trusted to issue ACs to users the enhanced distributed trust model that we from any domain, according to the RAP. wish to provide to target and origin sites can When the PERMIS PDP is passed a set of be obtained. However, a number of attribute certificates by Shibboleth, it can misalignments between PERMIS and determine from the RAP which are trusted Shibboleth need to be addressed first. Either to keep, and which should be discarded as Shibboleth needs to transfer X.509 attribute untrusted. All the trusted attributes are certificates (ACs) from the origin site to the extracted and stored for later access control resource site instead of plain attributes, or decision making. PERMIS needs to be modified to accept plain attributes instead of X.509 ACs. In The PERMIS policy also contains the set of fact, both of these methods have been targets that are being protected by this implemented so as to provide resource sites policy, the associated actions that can be with the maximum of flexibility. We have performed on them (along with their modified the Shibboleth origin site to parameters), and the attributes (or roles) that retrieve X.509 ACs from its LDAP a user needs in order to be granted the directory, and to pass these as text encoded access. In addition, constraints can be placed binary attributes within the SAML attribute on these grants, such as, only between 9am assertions. This facility should be provided and 5pm, or only if the user holds non- as part of the standard Shibboleth software conflicting roles3, or only if the size is less release during 2005. We have also modified than 3Mbytes etc. This is called the target the code that calls the PERMIS PDP to access sub-policy (TAP). When the validate the plain attributes from Shibboleth PERMIS PDP is asked if a user with the and use these instead of or as well as X.509 3 ACs. Separation of duties is currently being implemented but is not in the current NMI release. Since it is the target site’s resources that are business lounge may be granted by being accessed, we are primarily concerned presenting frequent flyer cards from a with the trust that a target site is expected or number of different airlines or diners clubs.) required to have in the attributes that it On the other hand, if the target site is not receives in order for it to become Shibboleth willing to recognise these multiple enabled. An origin site will also have its authorities, then the origin site will need to own preferred trust model for the allocation (re-)sign all the SAML attribute assertions of attributes, but the target site’s trust model by the single authority that the target site is must always take precedence since it is the willing to trust. owner of the resources that are being accessed. We can look at trust from two Secondly, we consider the origin site’s different aspects: the distribution of trust in attribute repository (typically an LDAP the attribute issuing authorities (centralised server). If either the target or origin site do or distributed) and the trustworthiness of an not trust this to store unprotected attributes origin site’s attribute repository (trusted or securely, then the origin will need to store not). digitally signed attributes in it, rather than plain attributes. We now consider each Firstly, we consider the distribution of trust. combination in turn. Figure 1 pictorially In the simplest case the origin site has a represents each of the trust models shown in single attribute issuing authority. If the the following sections. target site trusts the origin site’s attribute authority, this authority can issue and sign 5.1 Target trusts origin’s attribute all the SAML attribute assertions. (This is repository and origin as a single the standard Shibboleth model.) attribute authority Alternatively, the origin site may wish to This is the original Shibboleth trust model distribute the management of attributes and both the target site and origin site will between different trusted authorities in its use standard Shibboleth. The origin will domain and to allow dynamic delegation of store plain attributes in its repository, and authority. If the target site wishes to pass them in digitally signed SAML distribute its trust to these different messages to the target. The target site may authorities, then it can allow (trust) each one use the standard Shibboleth authorisation of them to issue and sign different attribute mechanism, or optionally, for a finer grained assertions, and further decide if it will allow and more refined access control mechanism, dynamic delegation of authority to take use a policy controlled PDP to make place. Furthermore, in this distributed trust decisions. When using the PERMIS PDP for scenario, the target site may be willing to authorisation, the PERMIS target access trust, or even require, some attribute sub-policy (TAP) is used to say which authorities that are not even based at the attributes are needed in order to gain access origin site to issue attributes to users. (This to the targets, and the (unsigned) attributes is typically the case in today’s world when from the SAML message are passed to the one presents plastic cards from multiple PERMIS PDP. different issuers in order to gain access to a particular resource e.g. access to an airport Shibboleth Shibboleth Origin Target Shibboleth Shibboleth Domain Transfer attributes Domain Origin Target Domain Transfer ACs Domain TAP 5.1 Standard Shibboleth RAP/TAP 5.2 Multiple ACs at Origin Shibboleth Origin Domain Transfer DN Shibboleth Target Domain X Shibboleth Shibboleth Origin Target RAP/TAP Domain Transfer ACs Domain RAP/TAP 5.3 Pull ACs from multiple AAs 5.4 Untrustworthy attribute repository RAP= role assignment policy Shibboleth Shibboleth TAP=target access policy Origin Target Domain Transfer attributes Domain = attribute repository RAP TAP = AA 5.5 Multiple AAs at Origin not trusted by Target Figure1. Pictorial representation of different trust models this. Additionally, the target may allow 5.2 Origin wishes to distribute dynamic delegation of authority at the origin attribute assignments and target site, by specifying this in the RAP4. trusts different attribute Shibboleth now fetches attribute certificates authorities at the origin from the origin site, rather than plain In this scenario the origin distributes attributes. Consequently the SAML attribute management between multiple authorities assertions do no need to be signed, though and therefore must store attribute certificates the link will still need to be SSL encrypted if in its repository, so that the different privacy protection is required. In this attribute authorities can be recognised by the scenario the origin’s attribute repository target. The target site uses the role may or may not be trusted by either the assignment sub-policy (RAP) to describe target or the origin, but this is not an issue who it trusts to assign which attributes to since it is storing digitally signed ACs in the whom, and the TAP to determine which repository. attributes are needed in order to access which targets. Note that the target may only trust a subset of the actual attribute authorities at the origin site, according to its 4 Note that the enforcement of dynamic delegation of RAP, and the policy specification allows for authority is currently being implemented and will be in a future release of PERMIS. 5.3 Target trusts different attribute These should all be signed by the same authorities at the origin site and organisational attribute authority that is elsewhere trusted by the target. Shibboleth will then carry either signed attribute certificates or In this scenario, the target site wishes to signed SAML assertions to the target site. authorise users based on attributes assigned (Note that the latter is equivalent to the to them by different attribute authorities that model in 5.1). When the ACs are handed to are not always co-located with the origin the PDP, the RAP will check that they have site. In this case, the origin site cannot push been issued by the sole origin authority. The all the attributes to the target site (unless the TAP is then used to determine if the user has AAs have distributed them to the origin site sufficient attributes to be granted access to in the first place, which cannot be the target or not. When Shibboleth is guaranteed), so the target will need to transferring attribute certificates in the operate in pull mode and fetch the ACs that SAML assertions, the assertions do not need it needs directly from the AAs. The to be signed, though SSL encryption will be PERMIS PDP can operate in pull mode and needed if privacy protection is required. fetch all the attribute certificates that are needed from the various distributed (LDAP) 5.5 Origin wishes to distribute repositories. The SAML attribute assertions from the origin site do not need to carry any trust to multiple authorities, but attribute certificates in this instance. They target does not recognise them only need to provide the holder identity of In this scenario the target wishes to run the user, so that the target can know which standard Shibboleth but the origin wishes to ACs to retrieve. Of course, each attribute distribute the management of attributes to authority will need to let its repository different AAs i.e. to run its own PMI, with (LDAP server) be accessed by the target all the advantages this brings such as site5. Once the ACs have been retrieved, the dynamic delegation of authority. The origin target’s PDP will use the RAP to determine will be creating and storing attribute which ACs are trusted, and the TAP to certificates in its AC repository signed by determine if the user has the necessary multiple distributed attribute authorities. attributes to access the resource. However, because the target wishes to run standard Shibboleth, and wants a single 5.4 Target and/or origin do not point of trust at the origin, these ACs cannot trust origin’s attribute repository be passed to the target. Therefore the origin but target trusts origin as a single site should run a PDP with its own RAP to attribute authority validate that the ACs are issued in accordance with its own policy. This will In this scenario the origin cannot store validate the stored attribute certificates, unsigned attributes in its repository, but extract the attributes that are trusted and rather should store digitally signed attributes pass these to the local Shibboleth origin in its (LDAP) repository. The exact format server for transfer in signed SAML attribute of these could be X.509 attribute certificates assertions to the target. The target site can or (long lived) SAML attribute assertions. then run the standard Shibboleth authorisation module, or for finer grained 5 Note that if a site’s firewall prevents the LDAP control can run its own PDP and TAP, as in protocol from passing through, there are several http 5.1, to determine if the user is to be granted to ldap gateways available that allow the firewall to access or not. be tunnelled through on port 80. 6 User Privacy Issues identity of the user. With a group identity One of the limiting factors of X.509 attribute the target site would only be able to profile certificates (ACs) is that they bind the the whole group, and would not be able to attributes to the holder, and if the holder is differentiate between different group identified by their real name in the AC e.g. members, or know how many members {CN=David Chadwick, OU=Computing were in the group. Laboratory, O=University of Kent, C=GB} then the user’s privacy is (at least partially) Secondly, the holder can be identified lost. There are a number of solutions to this indirectly by reference to their X.509 public problem. X.509 ACs allow holders to be key certificate. In this case the attribute identified in a number of different ways. certificate holds the serial number and issuer Firstly, they can be identified by a name of the user’s public key certificate e.g. distinguished name (DN). However, this DN {x509serialNumber=123456 + x509issuer = does not need to be the real name of the {OU=Some CA, O=Some Org, C=US}. The holder or indeed in any way be similar to the limitations of this method are that the user holder’s real name. It can be a pseudonym must be PKI enabled, which of course, many rather than their real name e.g. are not; and that, depending upon the {CN=123456789}, or even a group name contents of the user’s public key certificate, e.g. {CN=Programmer, OU=Computing the user might be identified via this. Laboratory, O=University of Kent, C=GB}. This opaque name only needs to have Finally, the holder can be identified meaning to the issuing site. The mapping indirectly by reference to the hash of a between the user’s login/authentication public key that they hold. This is now identity and AC holder identity would be effectively a random number, giving good performed at authentication time by the privacy protection. The user can prove origin site’s authentication server. It is ownership of the attribute certificate by important to note that the binding between digitally signing a challenge provided by the the pseudonym in the AC and the origin authentication server, which can then authentication name of the human user is provide this AC to the target site. The handled not by normal PKI registration restrictions are that the user needs to be procedures, but by the origin authentication using some form of asymmetric system, so that the target site’s trust in user cryptography, has generated their own authentication has to be placed in the origin private/public key pair, has created a self site’s systems and not in a trusted third party signed certificate with a random DN and CA. Further, the use of pseudonyms or does not have a corresponding X.509 public group names will make it much more key certificate identifying him/her. The main difficult for independent AC issuers to limitation from a privacy perspective is that participate in distributed trust management, the target site can profile the user, without since they will need to liaise with the origin knowing the actual identity of the user, since site to know which opaque names have been the same public key hash is used each time. given to which users. In all these cases there is a trade-off between The difference between using a pseudonym the “degree of anonymity” and the “quality and a group identity is that in the former of issuance”. At one extreme we have case the target site would be able to profile dynamically generated Shibboleth short the user, without knowing the real physical lived signed SAML attribute assertions that provide anonymity but require a trusted message sent by the origin site, long lived directory to store the user’s attributes. At the ACs may have the overhead of requiring other extreme we have long lived ACs revocation list processing, depending upon where each attribute authority can issue its how they are stored and distributed. If the own attributes in a controlled manner, but ACs are stored in a repository under the without any privacy protection. At various control of the issuer, and are retrieved from points in the middle we have long lived ACs there by either the Shibboleth origin or with various forms of privacy protection target sites, or directly by the target’s PDP, (pseudonyms, group names and public key then a revocation list may be avoidable identifiers) where the AA or authentication providing the issuer deletes the ACs when system maps the user’s name into a privacy they need to be revoked, and third parties protected one. are not able to surreptitiously write them back again. In this way the revoked ACs In addition to protecting the identity of the will not be available to the PDP when either AC holder, the AC issuer name may also be it or the Shibboleth components try to protected in the same ways as above. Note retrieve them. If on the other hand the ACs that the name of the SOA may be privacy are not stored in a repository under the protected or pseudonymised in some way, control of the issuer, for example, they are but the target PDP will need to know who distributed directly to their holders, then this name actually belongs to if it is to be standard attribute certificate revocation lists configured as a root of trust. The privacy of (ACRLs) will be needed, and the issuer will the embedded attributes may be protected by need to periodically update them, in exactly encryption, as described in [3] and [7]. the same way as for public key certificate Different attributes can be encrypted for CRLs. The PDP will need to ensure that it different target sites. The main disadvantage has a current ACRL when validating the of encrypted attributes is that the issuer ACs that have been presented to it. This will needs to know in advance, when creating the cause some performance overhead at the AC, who the targets are going to be. This of target site. Short lived ACs on the other course may not always be possible with hand do not need ACRLs to be published, relatively long lived ACs, in which case SSL just as the short lived SAML assertions do encryption of the communications link is a no require them. Whilst short lived ACs do better option for attribute privacy. not have the distributed trust management benefits of long lived ones (one cannot 7 Revocation and Performance expect human managers to issue ACs to Issues their staff daily, whilst automated issuing The signed SAML assertions of Shibboleth servers have the same trust related problems do not need to be revoked due to their short as existing Shibboleth implementations), life times. Attribute certificates on the other they do have a significant performance hand are expected to have a relatively long benefit over signed XML messages [8] [9], life time, according to the so they might still be worthy of privileges/attributes being allocated. For consideration in this respect. example, one might expect a “student” attribute certificate to be valid for an entire 8 Conclusions academic year. Whilst signed SAML We have shown how a distributed, finer attribute assertions have the performance grained and more functional trust model can overhead of requiring a digital signature per be added to Shibboleth, to increase the latter’s flexibility and authorisation decision [6] OASIS. “eXtensible Access Control making capabilities. We have further shown Markup Language (XACML)” v1.0, 12 Dec how the model can support target and origin 2002, available from http://www.oasis- sites using different combinations of open.org/committees/xacml/ centralised and distributed trust models, and [7] S. Farrell, R. Housley. “An Internet different assumptions concerning the Attribute Certificate Profile for trustworthiness of the origin’s attribute Authorization”. RFC 3281, April 2002 repository. We have implemented this [8] Mundy, D. and Chadwick, D.W., "An distributed trust model in Shibboleth by XML Alternative for Performance and combining it with the PERMIS authorisation Security: ASN.1", IEEE IT Professional, infrastructure and X.509 attribute Vol 6., No.1, Jan 2004, pp30-36 certificates. Finally we have argued that user [9] “Fast Web Services,” P. Sandoz and privacy does not need to be compromised colleagues, Aug 2003, available from per se by using long lived X.509 attribute http://java.sun.com/developer/technicalArtic certificates instead of short lived digitally les/WebServices/fastWS/ signed SAML attribute assertions, although it is certainly more difficult to fully protect a user’s privacy in the former case. 8 Acknowledgements The authors would like to thank the UK JISC for funding this work under the SIPS project. 9 References [1] Scot Cantor. “Shibboleth Architecture, Protocols and Profiles, Working Draft 02, 22 September 2004, see http://shibboleth.internet2.edu/ [2] D.W.Chadwick, A. Otenko, E.Ball. “Role-based access control with X.509 attribute certificates”, IEEE Internet Computing, March-April 2003, pp. 62-69 [3] ISO 9594-8/ITU-T Rec. X.509 (2001) The Directory: Public-key and attribute certificate frameworks [4] David Chadwick, Sassa Otenko, Von Welch. “Using SAML to link the GLOBUS toolkit to the PERMIS authorisation infrastructure”. Proceedings of Eighth Annual IFIP TC-6 TC-11 Conference on Communications and Multimedia Security, Windermere, UK, 15-18 September 2004 [5] OASIS. “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1”, 2 September 2003 Adding Distributed Trust Management to Shibboleth David Chadwick University of Kent NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 1 Contents • Introduction to Shibboleth • Limitation of Shibboleth • Features of an Enhanced Trust Model • Introduction to PERMIS X.509 PMI • Combining Shibboleth and PERMIS together • Privacy protection in X.509 PMIs/PERMIS • Revocation and Performance Issues NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 2 What is Shibboleth? • Web based authentication and authorisation system that enables single sign on • User always authenticates to his home (origin) site • User’s attributes are transferred to target site to provide authorisation • User’s name does not have to be revealed, so privacy protection • Uses PKI certificates and digital signatures to authenticate message exchanges between sites NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 3 Shibboleth Authentication Handle WAYF Service H S t to Y F Web Service 5. r ec A e -di to W Signed 3.R rect e- di SHIRE Handle 2 . R 4. t Us e s u e Local q ra re ut Site r se he U nt . ica 1 tio AA Target Site n Server User Origin Site NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 4 Shibboleth Authorisation Handle Service Web Service SHIRE 6.Handle SHAR Local Site 9. Attributes A Q M 7. tes Shib tribu a t Authzn w ith d AA . A RM n te Server 8 ra g ) s s d Target Site c e c nie . A de Origin Site 10 (or User NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 5 Deficiencies in Shibboleth • Limited trust model. Target site trusts origin site and vice versa. Period – Single key pair held by each site – No differentiation between authorisation and attribute authorities – No support for dynamic delegation of authority – Limited authzn decision making capability – Implementations often use a single centrally administered LDAP server or other repository as source of both authentication and authorisation data – Target site does not know if the presented attributes are the correct ones for a given user, who allocated them, or if they are still valid • Using an X.509 Privilege Management Infrastructure solves all these problems NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 6 An Enhanced Trust Model • Multiple attribute authorities should be able to issue attributes and the target should be able to choose which ones it trusts • All the attribute authorities should not need to be resident at the origin site • The trust infrastructure should support dynamic delegation of authority • The target site should not have to rely on the security of the origin site’s repository NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 7 What is PERMIS? • It is a policy controlled role based authorisation system that uses digitally signed X.509 attribute certificates to hold users roles/attributes – its an X.509 PMI • It can work with any and every authentication system (Shibboleth, Liberty, Kerberos, PKI, username/PW, etc.) • Given a username, a target and an action, PERMIS says whether the user is granted or denied access based on the policy for the target domain • The policy says which roles/attributes users must have to access which targets and under what conditions • It can work in push or pull mode (user attribute certificates are sent to PERMIS, or PERMIS fetches them itself). Conforms to ISO 10181-3 model NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 8 Authorisation Framework (from X.812|ISO 10181-3 and RFC 2753) Target Site User’s Site AEF= application dependent Access control Enforcement Function or User PUSH Credentiials PEP= Policy Enforcement Point Initiator Submit Internet AEF/PEP Present Target Access Access Request Request Decision Decision Request PULL User ADF/PDP Credentiials Policy Policy ADF= application independent Access control Decision Function or PDP = Policy decision point NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 9 PERMIS System Authentication Service Submit Initiator Access Present PEP Target Request Access Decision Request Retrieve Request SAMLDecision Role ACs (push) The PERMIS Java API Privilege Validator PDP PKI LDAP Retrieve Policy Directories and Role ACs (pull) NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 10 Distributed Management LDAP Directory Push Mode Attribute Certificates Application Gateway Target LDAP Directory The PERMIS PMI API PERMIS API Implementation PDP Pull Mode Site based managers (Remote SoAs) Policy LDAP Directory Target Manager (SoA) NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 11 PERMIS Trust Model • The Target/Resource is the root of trust (Source Of Authority SoA) for access to itself • The Target is configured with its SoA name at start up • The Policy is signed by the SoA (Permis checks this) • The SoA says in the policy which remote SoAs it trusts to allocate roles • The SoA says what roles they can allocate • The SoA says what access rights are given to each role • The remote SoAs authenticate the users and allocate roles to them NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 12 PERMIS Policy • Each policy has a unique OID, is put in an X.509 AC and digitally signed by the target SoA • Role Assignment Policy (RAP) – Defines the role hierarchy and – Says which roles remote SoAs are trusted to assign to which sets of users, and whether dynamic delegation of authority is allowed or not • Target Access Policy (TAP) – Says which roles can access which resources under which conditions • Coming soon – Static and Dynamic Separation of Duties/Mutually Exclusive Roles and support for Dynamic Delegation of Authority in the PDP NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 13 Shibboleth with PERMIS Authorisation Apache Server SHIRE 6.Handle SHAR 9. Attributes The PERMIS API Q M AC s mod_ 7 . A te s or JNI Privilege PDP u connector th a ttrib permis 10.Authzn Validator wi RAP TAP RM 8. A Decision Authzn Policy LDAP Directory NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 14 Apache with PERMIS Authorisation Apache Server User request LDAP Apache Authentication Directory Authzn Policy mod_ The PERMIS API permis JNI Privilege connector Validator PDP LDAP Directory Pull ACs NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 15 Shibboleth Shibboleth Origin Target Shibboleth Shibboleth Domain Transfer attributes Domain PDP Origin Target Domain Transfer ACs Domain PDP RAP/TAP 1 Standard Shibboleth RAP/TAP 2 Multiple AAs at Origin Shibboleth Origin Domain Transfer DN Shibboleth Target Domain PDP X Shibboleth Shibboleth RAP/TAP Origin Target Domain Transfer ACs Domain PDP RAP/TAP 3 Pull ACs from multiple AAs 4 Untrustworthy attribute repository Shibboleth RAP= role assignment policy Shibboleth Origin Transfer attributes Target PDP TAP=target access policy Domain PDP Domain PDP = = attribute repository RAP TAP PERMIS PDP 5 Multiple AAs at Origin not trusted by Target = Attribute Authority NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 16 Privacy Issues • X.509 ACs bind attributes to a holder, usually their DN – E.g. {CN=David Chadwick, OU=Computing Laboratory, O=University of Kent, C=GB} • But does not have to be the real name of the user – Pseudonym {CN=123456789, O=University of Kent, C=GB} – Group name {CN=Programmer, OU=Computing Laboratory, O=University of Kent, C=GB} • Can also be a pointer to user’s PKC – {x509serialNumber=123456 + x509issuer = {OU=Some CA, O=Some Org, C=US}} • Or a hash of a public key – {rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467 GhIGfHfYT6} • Trade-off between the “degree of anonymity” and the “quality of issuance”. NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 17 Revocation and Performance Issues • Signed SAML assertions in Shibboleth are short lived so don’t need to be revoked but have overhead of signing per message • X.509 ACs are signed so don’t need secure channel for communication. But typically long lived so either need ACRLs or repositories under control of issuer so ACs can be deleted • Could use short lived ACs but then wont be generated by a human and are same as short lived SAML assertions • ACs typically faster to create and validate than signed XML assertions NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 18 Attributes, Anonymity, and Access: Shibboleth and Globus Integration to Facilitate Grid Collaboration Von Welch,1 Tom Barton,3 Kate Keahey,2 Frank Siebenlist2 1 National Center for Supercomputing Applications, University of Illinois 2 Mathematics and Computer Science Division, Argonne National Laboratory 3 Networking Services & Information Technologies, University of Chicago Abstract protecting individual privacy while still providing basic security services to system In this paper we describe our work in owners. progress to integrate the Shibboleth SAML- based framework and Globus Toolkit’s PKI- In this paper, we present our work to address based security infrastructure. The result will this issue by integrating two widely accepted provide identity federation and attribute- technologies: Shibboleth [20], an Attribute based policy enforcement for Grids that Authority service developed by the Internet2 leverages the Shibboleth system being community for cross-organization identity deployed on campuses. We provide an federation, and the Globus Toolkit’s [10] overview of both Shibboleth and the Globus Grid Security Infrastructure (GSI) [26]. Our Toolkit, present our motivating use cases, project, which is funded by the NSF and describe our planned integration work. National Middleware Initiative [16], is known informally as “GridShib” [11]. The 1 Introduction objective is to provide mechanisms whereby a Grid service can authenticate a user using As virtual organizations (VOs) [9] GSI, determining the address of the increasingly turn into distributed multi- Shibboleth attribute service in the process, institutional collaborations, secure and then obtain from the Shibboleth service authentication and authorization become a the select user attributes that the Grid growing challenge. In the existing Grid [8] service is authorized to see. Attributes infrastructure to support VOs, these obtained in this way can then be used by the mechanisms are typically based on the Grid service in making authorization identities of the interacting entities. While decisions. this approach is simple and intuitive, as VOs expand, it becomes impractical to In Section 2, we describe Shibboleth and the administer. VO membership may change relevant security portions of the Globus dynamically, rights may be granted to Toolkit. Section 3 introduces the use cases entities on a periodic basis, or a user’s role we plan to address. In Section 4 we discuss in an organization might dynamically our plans for the Globus-Shibboleth evolve. Such factors make it more practical integration, describing modes of usage, to express users’ rights based on their other technical details, and planned attributes, such as institutional affiliation or implementation. In Section 5 we compare role in a collaboration, rather than identity related technologies. In Section 6 we alone. summarize our plans and conclude the paper. Indeed, it may be desirable to enable anonymous interactions between users, thus 2 Background policies on the release of these attributes, allowing the user to specify which In this section we provide an overview of targets can access which attributes. The the two software products relevant to our Shibboleth Attribute Authority retrieves work: Shibboleth and the Globus Toolkit. A attributes from an organizational more detailed description of Shibboleth [20] authority and provides them in the form and the Globus Toolkit [10] can be found on of SAML assertions. As is the case with the individual Web sites. We also describe the Handle Service, the Attribute the authentication standards used by each of Authority is intentionally neutral to the these software systems. specific implementation of the organizational attribute service; LDAP is 2.1 Shibboleth typically used today Shibboleth is a system that asserts attributes • Target Resource: The target resource about a user between organizations. More includes Shibboleth-specific code to precisely, it asserts attributes between the determine the user’s home organization user's home organization and organizations and hence which Shibboleth attribute hosting resources that may be accessible to authority should be contacted for the the user. By using an attribute-based user, to retrieve attributes regarding the authorization model, the Shibboleth user, and to make authorization architecture is able to protect user privacy decisions based on those attributes. better: identifying information may, but need not, be among the attributes presented In normal Shibboleth usage, a new handle about the user. token is acquired each time the user accesses a different resource. A handle token can be Shibboleth can be conceptually regarded as reused on returning to a resource for a comprising three components: relatively short period of time. Each handle • Handle Service: The Handle Service token has a different unique identifier for the authenticates users in conjunction with a user that is meaningful only to the local organizational authentication Shibboleth attribute authority. As a result, a service and issues to the user a handle target resource cannot rely on the handle to token. The handle token (comprising a learn the true identity of a Shibboleth user, SAML authentication assertion [19]) is a nor can it correlate subsequent accesses as bearer credential containing an coming from the same user. identifier, or handle. The Handle Service The current implementation of Shibboleth is intentionally neutral to the choice of (version 1.2) is primarily designed to the organizational authentication function with Web applications (i.e., mechanism and can function with almost standard Web servers and browsers). Plans any such service (e.g., LDAP [25]). for future implementations (starting with • Attribute Authority: When a user version 1.3) include support for non-Web requests access to a target resource, he applications. presents his handle token. The resource Figure 1 shows the typical operation of then presents the user’s handle token to Shibboleth. A number of steps not relevant the attribute authority and requests to this paper are omitted for clarity. attributes regarding the user. The attribute authority enforces privacy whether communication of the requested user attributes is allowed. If so, the requested attribute values are retrieved. 8. The Shibboleth attribute authority casts the attributes in the form of a SAML attribute assertion and returns the assertion to the target resource. 9. (Not shown) After receiving the attributes from Shibboleth, the target resource makes an authorization decision regarding the user's request based on those attributes. Figure 1: Simplified Shibboleth architecture and 2.2 Globus Toolkit typical usage. Steps are described in the text. The Globus Toolkit provides basic The steps shown in Figure 1 are as follows: functionality for Grid computing [8], with 1. The user connects and authenticates to services for data movement and job the Handle Service. submission, and a framework on which higher-level services can be built. The Grid 2. The Handle Service uses a local organizational authentication service to in general has been adopting Web services verify the user’s authentication technologies, and this trend is reflected in recent versions of the Globus Toolkit in information. following the Open Grid Services 3. The Handle Service creates a new handle Infrastructure [24] and now the Web to identify the user. This handle is Services Resource Framework [29] registered with the attribute authority so standards. This convergence of Grid and that it can be mapped to the user’s Web services was part of our motivation for attributes when a request from a resource adopting Shibboleth in our project (which arrives. uses the SAML standard). 4. The handle is placed into a handle token and returned to the user. The Grid Security Infrastructure, on which the Globus Toolkit is based, uses X.509 5. The user sends a request to a target identity certificates [12] and X.509 proxy resource and presents the handle token. certificates [23, 27]. In brief, these 6. The resource examines the handle token certificates allow a user to assert a globally to determine which Shibboleth service unique identifier (i.e., a distinguished name can provide attributes about the user. It from the X.509 identify certificate). contacts that Shibboleth service and requests attributes, providing the handle We note that in Grid scenarios there is often token to identify the user. a clear separation between the certificate 7. After validity checks have been authorities (CAs), which are the authorities performed on the handle token and the of identity, and the authorities of attributes handle has been mapped to the user’s or authorization. For example, in the case of identity, the applicable attribute release the DOE SciDAC program [18], a single policy for that resource is checked CA, the DOE Grids CA [3], serves a broad community of users, while the attributes and In this scenario, authorized users of the Grid rights for those users are determined by their service are located at one or more campuses individual projects (e.g., National Fusion and can be described by some campus- Grid, Earth Systems Grid, Particle Physics oriented attribute (e.g., chemistry professor). Data Grid). Verifying this attribute at their home institution authorizes user access to the Grid Authorization in the Globus Toolkit is based services. on access control lists for each resource that specify the identifiers of the users allowed to An example of where this service could be access the resource. Higher-level services to applied in a Grid context is TeraGrid [1]. provide richer authorization exist; we Each site on TeraGrid could operate a discuss these, and their relationship to this Shibboleth service in order to identify their work, in Section 5. staff and user community. This would enable TeraGrid resources to be easily 2.3 GridLogon/MyProxy available to the entire TeraGrid community without having comprehensive access GridLogon is a credential service being control lists maintained on the resource. developed at NCSA as an extension to the popular MyProxy service [15]. MyProxy is a credential management service and is the de facto mechanism used to provide security to Grid portals worldwide. Simply put, GridLogon acts as an online- CA, authenticating the user through a variety of mechanisms and issuing (short- lived) X.509 identity credentials suitable for use with Grid resources. GridLogon will provide a pluggable authentication mechanism to allow for the use of different Figure 2: Scenario showing users being authorized local authentication systems, such as based on their campus-assigned attributes. username/password, One-Time-Password, 3.2 Project-Operated Kerberos, and Public Key. Shibboleth Service 3 Motivating Use Cases Figure 3 depicts a different scenario, where In this section, we describe the use cases we the project deploys and operates its own wish to support with our work. attribute authority. This scenario has the benefit that the project can freely assign 3.1 Project Leveraging Campus attributes and add users as it wishes, without Attributes involving campus administration staff. However, the project must itself operate the The first scenario, shown in Figure 2, Shibboleth service, a critical requirement resembles the basic model in which from the perspective of both security and Shibboleth is used today, except that the reliability. This approach is beyond the target resource is a Grid service instead of a scope or capabilities of many projects. Web-based application. While we believe this hybrid approach to be the best of the three scenarios, it does require some form of administration delegation capabilities that is not present today. We address this issue in Section 4.3. 4 GSI-Shibboleth Integration Our work comprises five major components: • Assertion Transmission – to enable the transmission of assertions from the Shibboleth service to the Grid software and ultimately the Grid runtime Figure 3: Scenario showing Shibboleth service authorization decision-making operated by a project. component. 3.3 Campus-Operated, Project- • Attribute Authority – to enable discovery Administered Approach of the appropriate attribute authority for a user in the Grid context. Since Grid The scenario shown in Figure 4 is a hybrid resources serve users from multiple of the two preceding scenarios. It empowers organizations, a mechanism is needed to the project to administer its own attribute determine which organization’s space while allowing the Shibboleth service Shibboleth service is authoritative for a to be maintained by campus staff who are particular user. expert in running such services. • Distributed Attribute Administration – to manage subsets of an attribute space served by a Shibboleth service by projects outside the domain operating the Shibboleth service (as described in Section 3.3). • Pseudonymous Interaction – to extend to Grids the pseudonymous interaction provided by Shibboleth. • Authorization – to provide a mechanism that is integrated with the Globus Toolkit and can take advantage of the attributes. 4.1 Assertion Transmission The fundamental engineering problem that Figure 4: Scenario showing hybrid mode of must be solved is how to transmit user operation, with the campus operating the attributes from a Shibboleth attribute service Shibboleth service and the project administering to the Grid resource so that an authorization its portion of the attribute space. decision can be made utilizing those the upcoming release of Shibboleth (version attributes. 1.3) will support a generalized version of this mapping feature capable of supporting Two fundamental modes of operation DNs, which will solve the basic problem of address this problem: mapping identifiers. • Pull mode: The target Grid service, after authenticating the user, will contact the 4.2 Attribute Authority appropriate Shibboleth service to obtain Discovery attributes regarding the user. This is One issue in distributed systems that serve analogous to normal Shibboleth users from multiple communities is operation today, as described in Section determining which organization a particular 2.1. user is from and hence the organization • Push mode: The Grid user, before whose attribute authority that can provide contacting a target service, will contact attributes regarding the user. This is often an appropriate Shibboleth service to referred to as the “Where are you from?” obtain attributes and then convey those (WAYF) problem. to the target Grid service at the time of Shibboleth currently addresses this problem making a request. This is analogous to by asking users to identify their home how other attribute authority systems in organization when they attempt to access the the Grid context work today, described target resource. In its current model of in Section 5. supporting interactive Web browser-based The pull mode of operation has the applications, this approach is acceptable. In advantage of being more easily deployed; the Grid context, however, where the user since clients of services are not affected and may be using client software that does not do not even need to know Shibboleth is support this level of interactivity or the involved in their decision-making. However, client may be an unattended batch job, we as we describe in the subsequent section on need a different approach. Attribute Authority discovery, the push We will explore the following possible mode has the advantage of allowing a user solutions: to select a particular role. Hence we plan on implementing both, to allow for flexible • Use the push mode of operation, deployment to meet the requirements of described in Section 4.1 and have the different projects. user select the attribute authority to contact. This approach has been taken by Regardless of the mode chosen, there exists other systems, such as VOMS described the issue of federating the Grid identities, in Section 5.1. The main drawback is which consist of X.509 distinguished names that it requires modification of client (DNs), with the local identities used by the behavior or software, which can present organization operating the Shibboleth a deployment challenge. service. This federation will require that a mapping be performed between the DN and • Place a pointer (e.g., a hostname) to the the local site identifier. Shibboleth, as attribute authority to contact in the user’s described in Section 2.1, already performs a X.509 identity certificate. This solution similar mapping from the handle issued by requires cooperation of the CA issuing the Handle Service to the local identity, and the user’s identity credentials, which may not always be available, and also This attribute management model does not binds attribute information to the user’s support resource targets wanting to use identity credential, which may raise attributes that are asserted by other problems if the lifetimes of these two authorities. One example is an issue that is elements are not in synch. already being faced by the Shibboleth community and is known as the “IEEE • Place a pointer to the attribute problem”: having universities provide IEEE authority’s location in the user’s proxy membership status to allow resource targets certificate. Since the user can create to authorize based on their IEEE proxy certificates fairly easily and with membership rather than on their campus short lifetimes, this approach solves a affiliation. While the authoritative party for number of problems with having the the attributes, IEEE in this case, could issuing CA place information in longer- establish its own Shibboleth service, this term identity certificates. The actual approach may not always be desirable placing of the information could because some organizations may not have probably be automated, and users could the resources or skills to operate a highly select from different attributes available secure attribute authority service. authorities, and even multiple authorities, depending on the specific A new privilege management system called role or roles they want to adopt. Signet [21], which is being developed by a working group of the Internet2 Middleware A related challenge that we will explore is a Initiative, supports the distributed scenario where a user may be acting in a administration of privileges. Shibboleth- role that combines attributes from multiple enabled access to Signet is planned, which organizations or from the project and an will enable authorities outside of the organization. In this scenario the user’s administrative domain in which a Signet attributes would come from multiple instance is operated to be delegated the Shibboleth services. It remains unclear at ability to manage a portion of the attribute time whether this is a true requirement for a space that can be asserted by that domain’s user community, so our exploration of this attribute authority. This arrangement has the problem may be minimal. potential to support the use case described in Section 3.3. 4.3 Distributed Attribute Administration In collaboration with the Signet development team, we will explore the The current Shibboleth attribute possibility of allowing administrative management paradigm assumes that the delegation of the attribute space in a single complete attribute space asserted by a attribute authority service among multiple particular attribute authority is managed organizations as a means to solve this within a single administrative domain. This problem. model makes sense when all the attributes are concerned with the user’s role in the 4.4 Pseudonymous Access single domain; for example, if the administrator works for the user’s university Shibboleth allows for pseudonymous access and the attributes all concern the user’s as part of its normal operation. To provide position at the university. anonymity in the Grid context, we will integrate the GridLogon service with Shibboleth and the Globus Toolkit. As we provide attributes received from Shibboleth described in Section 2.3, the GridLogon to those external authorization services in service issues X.509 certificates to order to allow them to incorporate those authenticated clients. We will implement an attributes in their decision-making process. extension to GridLogon module that issues an authenticated client a set of credentials In parallel with our GridShib effort, the with a pseudonym identifier, which will Globus Toolkit team has also started work make the GridLogon service essentially act on a more ambitious authorization- as the Shibboleth Handle Service normally processing framework. As the toolkit is used does. GridLogon will register the by many different Grid applications and pseudonym with the Shibboleth attribute projects worldwide, it cannot mandate service, such that subsequent queries can be specific security technologies and mapped to the user’s attributes. mechanisms, and has to adopt a modular approach to accommodate the choices made 4.5 Authorization Mechanism by those responsible for deployment. For example, identity and attribute assertions To allow for the use of attributes in the have to be supported in X.509 Identity and Globus Toolkit runtime, we need to extend Attribute Certificate, Kerberos, and SAML the current ACL-based authorization Identity and Attribute Assertion formats. mechanism to encompass attribute-based Furthermore, all these statements can either policy. We intend to leverage existing be available in local storage within the standards and implementations here to the trusted computing base of the relying party, greatest extent possible. Our implementation be pushed by other parties via SOAP will most likely be very simple at first, for headers or Proxy Certificate embedding, be example, using attributes in place of pulled from online services, or external identities to map users to local accounts. attribute and authorization services can be queried through Shibboleth/SAML call-out We will explore the integration of XACML interfaces. [6] with the Globus Toolkit security runtime, with a mapping of SAML attribute In the first step of this authorization assertions to XACML attribute assignments processing, the received and collected as described in [14]. The result will be a assertions with their associated issuers are Web services runtime that can make verified and validated. The resulting authorization decisions about the user’s attribute statements with their issuer-subject invocation request of the Web service information are subsequently translated and operations based on the Shibboleth user’s mapped by mechanism specific Policy attribute and XACML policy rules. The aim Information Points (PIPs) into a common is to make the attribute retrieval and the format that is presented to the Policy evaluation and enforcement of the Decision Point (PDP). Our GridShib effort authorization policy transparent to the should be able to leverage this authorization application. framework development work. The Globus Toolkit currently supports an 4.6 Planned Timeline authorization callout [28], which allows external services to provide authorization The GridShib project officially began in decisions for Globus deployments as December 2004. Prior to that date we had described in Section 5.3. Our goal is to identified requirements and made preliminary project plans. We are now pseudonymous mode or have any other focusing on implementing the pull mode as provision for privacy. described in Section 4.1; we expect to have a first release by the summer of 2005 based 5.3 Akenti and PERMIS on the upcoming release of Shibboleth Akenti [22] and PERMIS [2] are (version 1.3) and a post-4.0 version of the authorization systems that have been Globus Toolkit. Enabling the push mode and integrated with the Globus Toolkit through pseudonymous access will follow in 2006. the use of authorization callouts [13,28]. Both Akenti and PERMIS allow for the use 5 Related Work of X.509 attribute certificates to make Our work is distinguished from related work attribute-based authorization decisions. We mainly through the Shibboleth support for envision our work as being complementary pseudonymous interaction, its fine-grained to these systems. Our focus falls on the attribute release policy, and its existing technology to transport SAML assertions broad support base in the Internet2 from the Shibboleth attribute authority to the community. Globus Toolkit-based services, whereas these systems are designed primarily as 5.1 VOMS authorization decision makers. We envision a mode of operation in which these systems The virtual organization management can be used to provide rich authorization service (VOMS) [5] was developed by the capabilities using Shibboleth-issued SAML European Data Grid project to allow for assertions in addition to the X.509 attribute attribute-based authorization to the Globus certificates they use today. Toolkit job management services. It uses X.509 attribute certificates [7] in a push 5.4 Signet mode to assert attributes in a modified version of the Globus Toolkit. The Signet privilege management system [21] is being developed by a working group We believe that Shibboleth, with its use of of the Internet2 Middleware Initiative. SAML, will be more easily interoperable Signet can manage privileges that are with Web services-based technologies expressed as attributes asserted by emerging in the Grid community. VOMS Shibboleth. Signet itself is planned to be also does not support a pseudonymous “Shibbolized” to support delegation of mode, nor does it have any other provisions privilege management beyond the bounds of for privacy support. a single organization. 5.2 CAS As discussed in Section 4.3, we plan to collaborate with the Signet team, in order to The Community Authorization Service enable Signet to manage the access policy to (CAS) [17] is similar to Shibboleth in its use Grid resources. of SAML assertions. However CAS operates at the level of capabilities rather than 5.5 ESP-Grid Project attributes; that is, instead of expressing abstractly what someone is, CAS expresses The ESP-Grid project [4] is evaluating how explicitly what actions they are allowed to Shibboleth could be used to benefit Grid take. CAS also does not support a authentication. We have met with the members of the ESP-Grid project and will stay in contact, sharing experiences and tbarton@uchicago.edu results of our work. Kate Keahey 6 Conclusion keahey@mcs.anl.gov We have described the motivations for Frank Siebenlist identity federation and for attribute-based franks@mcs.anl.gov authorization in Grids. We have described our plans for addressing these motivations Von Welch through integration of Shibboleth and the vwelch@ncsa.uiuc.edu Globus Toolkit in order to produce a system capable of enabling attribute-based authorization in Grids, leveraging existing References campus Shibboleth infrastructure, and 1. Catlett, C. The TeraGrid: A Primer, allowing for pseudonymity. 2002. www.teragrid.org. 2. Chadwick, D.W. and Otenko, A., The Acknowledgments PERMIS X.509 Role Based Privilege Management Infrastructure. 7th ACM This work is funded by the NSF National Symposium on Access Control Models Middleware Initiative, under award SCI- and Technologies, 2002. 0438424. 3. DOEGrids Certififcate Service, Our work would not be possible were it not http://www.doegrids.org, 2004. for our collaboration with the Internet2 4. ESP-GRID – Evaluation of Shibboleth Shibboleth development team chaired by and PKI for GRIDS. http://e- Steve Carmody. science.ox.ac.uk/oesc/projects/index.xml .ID=body.1_div.20, 2004. We also thank Ian Foster and Ken 5. EU DataGrid, VOMS Architecture v1.1. Klingenstein for their advice and guidance. 2003. http://grid- “Globus Toolkit” is a registered trademark auth.infn.it/docs/VOMS-v1_1.pdf. of the University of Chicago. 6. eXtensible Access Control Markup Language (XACML) 1.0 Specification, The submitted manuscript has been created OASIS, February 2003. by the University of Chicago as Operator of http://www.oasis- Argonne National Laboratory (“Argonne”) open.org/committees/xacml/ under Contract No. W-31-109-ENG-38 with 7. Farrell, S., and Housley, R., An Internet the U.S. Department of Energy. The U.S. Attribute Certificate Profile for Government retains for itself, and others Authorization. RFC 3281, IETF, April acting on its behalf, a paid-up, nonexclusive, 2002. irrevocable worldwide license in said article 8. Foster, I., and Kesselman, C. (eds.). The to reproduce, prepare derivative works, Grid 2: Blueprint for a New Computing distribute copies to the public, and perform Infrastructure. Morgan Kaufmann, 2004. publicly and display publicly, by or on 9. Foster, I. Kesselman, C., and Tuecke, S. behalf of the Government. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. Author Contact Information International J. Supercomputer Applications, 15(3), 200–222, 2001. Tom Barton 10. Globus Toolkit. http://www.globus.org/, 22. Thompson, M., Johnston, W., 2004. Mudumbai, S., Hoo, G., Jackson, K., and 11. GridShib Project Web site, Essiari, A., Certificate-based Access http://grid.ncsa.uiuc.edu/GridShib Control for Widely Distributed 12. Housley, R., Polk, W., Ford, W., and Resources. 8th Usenix Security Solo, D., Internet X.509 Public Key Symposium, 1999. Infrastructure Certificate and Certificate 23. Tuecke, S., Welch, V. Engert, D., Revocation List (CRL) Profile. RFC Thompson, M., and Pearlman, L., 3280, IETF, April 2002 Internet X.509 Public Key Infrastructure 13. Keahey, K., Welch, V., Lang, S., Liu, B. Proxy Certificate Profile, RFC 3820, and Meder, S.. Fine-Grain Authorization IETF, 2003. Policies in the Grid: Design and 24. Tuecke, S., et. al. Open Grid Services Implementation. In 1st International Infrastructure (OGSI) Version 1.0, Workshop on Middleware for Grid Global Grid Forum, 2003. Computing, 2003. 25. Wahl, M., Howes, T., and Kille, S., 14. Lorch, M., Proctor, S., Lepro, R., Lightweight Directory Access Protocol Kafura, D., and Shah, S., First (v3), RFC 2251, IETF, 1997. Experiences Using XACML for Access 26. Welch, V., Siebenlist, F., Foster, I., Control in Distributed Systems, ACM Bresnahan, J., Czajkowski, K., Gawor, XML Security Workshop, October 2003. J., Kesselman, C., Meder, S., Pearlman, 15. Novotny, J., Tuecke, S., and Welch, V., L., and Tuecke, S., Security for Grid An Online Credential Repository for the Services. In 12th IEEE International Grid: MyProxy. In Proceedings of the Symposium on High Performance Tenth International Symposium on High Distributed Computing, (2003). Performance Distributed Computing 27. Welch, V., Foster, I., Kesselman, C., (HPDC-10), IEEE Press, August 2001 Mulmo, O., Pearlman, L., Tuecke, S., 16. NSF Middleware Initiative (NMI). 2004. Gawor, J., Meder, S. and Siebenlist, F.. www.nsf-middleware.org. X.509 Proxy Certificates for dynamic 17. Pearlman, L., Welch, V., Foster, I., delegation. In Proceedings of the 3rd Kesselman, C. and Tuecke, S., A Annual PKI R&D Workshop, 2004. Community Authorization Service for 28. Welch, V., Ananthakrishnan, R., Meder, Group Collaboration. IEEE 3rd S., Pearlman, L., and Siebenlist, F., Use International Workshop on Policies for of SAML for OGSA Authorization Distributed Systems and Networks, (work in progress), Global Grid Forum, 2002. May 14, 2004. 18. Scientific Discovery through Advanced 29. WS-Resource Framework. Computing (SciDAC), http://www.globus.org/wsrf/, http://www.scidac.org, 2001. http://www.oasis- 19. Security Assertion Markup Language open.org/committees/tc_home.php?wg_a (SAML) 1.1 Specification, OASIS, bbrev=wsrf, 2004. November 2003. 20. Shibboleth Project, Internet2, http://shibboleth.internet2.edu/ 21. Signet, http://middleware.internet2.edu/signet/, 2004. Attributes, Anonymity, and Access: Shibboleth and Globus Integration to Facilitate Grid Collaboration 4th Annual PKI R&D Workshop Tom Barton, Kate Keahey, Frank Siebenlist, Von Welch Outline • Overview of Shibboleth and Globus • Our Motivation and Use Cases • Integration Approach April 19, 2005 4th Annual PKI R&D Workshop 2 Shibboleth • http://shibboleth.internet2.edu/ • Internet2 project • Allows for inter-institutional sharing of web resources (via browsers) – Provides attributes for authorization between institutions • Allows for pseudonymity via temporary, meaningless identifiers called ‘Handles’ • Standards-based (SAML) • Being extended to non-web resources April 19, 2005 4th Annual PKI R&D Workshop 3 Shibboleth • Identity Provider composed of single sign-on (SSO) and attribute authority (AA) services • SSO: authenticates user locally and issues authentication assertion with Handle – Assertion is short-lived bearer assertion – Handle is also short-lived and non-identifying – Handle is registered with AA • Attribute Authority responds to queries regarding handle April 19, 2005 4th Annual PKI R&D Workshop 4 Shibboleth • Service Provider composed of Assertion Consumer and Attribute Requestor • Assertion Consumer parses authentication assertion • Attribute Requestor: request attributes from AA – Attributes used for authorization • Where Are You From (WAYF) service determines user’s Identity Provider April 19, 2005 4th Annual PKI R&D Workshop 5 Globus Toolkit • http://www.globus.org • Toolkit for Grid computing – Job submission, data movement, data management, resource management • Based on Web Services and WSRF • Security based on X.509 identity- and proxy-certificates – Maybe from conventional or on-line CAs • Some initial attribute-based authorization April 19, 2005 4th Annual PKI R&D Workshop 6 Motivation • Many Grid VOs are focused on science or business other than IT support – Don’t have expertise or resources to run security services • Allow for leveraging of Shibboleth code and deployments run by campuses April 19, 2005 4th Annual PKI R&D Workshop 7 Use Cases • Project leveraging campus attributes – Simplest case • Project-operated Shib service – Project operates own service, conceptually easy, but not ideal • Campus-operated, project-administered Shib – Ideal mix, but need mechanisms for provisioning of attribute administration April 19, 2005 4th Annual PKI R&D Workshop 8 Integration Approach • Conceptually, replace Shibboleth’s handle-based authentication with X509 – Provides stronger security for non-web browser apps – Works with existing PKI install base • To allow leveraging of Shibboleth install base, require as few changes to Shibboleth AA as possible April 19, 2005 4th Annual PKI R&D Workshop 9 Integration Areas • Assertion Transmission • Attribute Authority Discovery • Distribute Attribute Administration • Pseudonymous Interaction • Authorization April 19, 2005 4th Annual PKI R&D Workshop 10 Assertion Transmission • How to get SAML assertions from AA into Globus? • Initially: Pull mode with Globus acting as a Shibboleth Attribute Requestor • Will explore Pull modes to help with privacy and role combination • Implement Grid Name Mapper to map X509 DNs to local identities used to obtain attributes April 19, 2005 4th Annual PKI R&D Workshop 11 Attribute Authority Discovery • No interactive WAYF service in the Grid • Place identifier of Identity Provider in cert – Either in long-term EEC or short-term Proxy Cert • Will explore pushing attributes – Avoids the problem – Might also address combined attributes from multiple AAs April 19, 2005 4th Annual PKI R&D Workshop 12 Distributed Attribute • Administration Campus is ideal for running services, but may not know all attributes of users • How does a campus issue attributes for which it is not authoritative? – E.g. IEEE Membership of staff – In Grid case, Project Membership • This may be the largest hurdle due to social, political and/or legal issues – Need accepted cookbook for process • Plan on exploring signet – http://middleware.internet2.edu/signet/ April 19, 2005 4th Annual PKI R&D Workshop 13 Pseudonymous Interaction • How to maintain Shibboleth pseudonymous functionality with X509? • Will develop online CA that issues certificates with non-identifying DNs – Register with AA just as SSO – Basically holder-of-key assertions April 19, 2005 4th Annual PKI R&D Workshop 14 Authorization • Develop authorization framework in Globus Toolkit • Pluggable modules for processing authentication, gathering and processing attributes and rendering decisions • XACML used for expressing gathered identity, attribute and policy information – Convert Attributes into common format for policy evaluation – Allows for common evaluation of attributes expressed in SAML and X509 (and others…) April 19, 2005 4th Annual PKI R&D Workshop 15 April 19, 2005 4th Annual PKI R&D Workshop 16 Status • Working on X509 profiles in OASIS • Initial pieces tested • Developing initial pull-mode prototype for initial evaluation April 19, 2005 4th Annual PKI R&D Workshop 17 Acknowledgements and Details • NSF NMI project to allow the use of Shibboleth-issued attributes for authorization in NMI Grids built on the Globus Toolkit – Funded under NSF award SCI-0438424 • Goal: GT 4.2 & Shibboleth 1.3 • GridShib team: NCSA, U. Chicago, ANL – Tom Barton, David Champion, Tim Freemon, Kate Keahey, Tom Scavo, Frank Siebenlist, Von Welch • Working in collaboration with Steven Carmody, Scott Cantor, Bob Morgan and the rest of the Internet2 Shibboleth Design team April 19, 2005 4th Annual PKI R&D Workshop 18 Questions? • Project website: – http://grid.ncsa.uiuc.edu/GridShib/ April 19, 2005 4th Annual PKI R&D Workshop 19 XPOLA – An Extensible Capability-based Authorization Infrastructure for Grids Liang Fang and Dennis Gannon Computer Science Department, Indiana University, Bloomington, IN 47405 Frank Siebenlist Mathematics and Computer Science Division, Argonne National Laboratory, Argonne, IL 60439 {lifang,gannon}@cs.indiana.edu, franks@mcs.anl.gov ABSTRACT and sometimes impossible to stay with this supercomputer- There is great need for a secure, fine-grained, efficient, and centric model. For example, when a project has an user-friendly authorization infrastructure to protect the educational outreach program that encourages thousands of services in Grid community. Grid users and administrators grade school students to use services provided by the still have to deal with authentication and authorization issues research Grid, we cannot assume these students all have in the traditional supercomputer-centric fashion, especially Grid accounts on central resources. Indeed, for any research with the host account maintenance and certificate collaboration that does not have a strong centrally managed management. This paper proposes a capability-based organization that can exert influence over resource providers, infrastructure that provides a fine-grained authorization creating user accounts and managing Grid tools like Globus solution to Web service deployments, and also manages to can be a serious administrative problem if it involves more hide complex security issues from regular Grid users. than a few machines. Furthermore, it gives the resource providers and Specifically, in order to obtain access to a specific remote administrators the extensibility, flexibility and convenience resource, even just temporarily, a Grid user-to-be has to go to enforce their authorization policies at the resource with through the following steps: minimal efforts. First, she needs an X.509 certificate issued by a certificate 1. INTRODUCTION authority (CA) that is trusted by the remote host. The user is 1.1 The Grid and Its Security supposed to manage her private key securely, and make Since the end of the last millennium, the Grid technologies those credentials accessible to the Grid-enabled client have profoundly changed the way scientists compute by software. supporting collaboration and resource sharing securely As an alternative, a Grid portal solution provides the across multiple domains. Interests from academia and interface to Grid services through web servers and standard industry in Grid technologies lead to a series of frameworks web browsers. This is definitely seen as a relief by the users and applications, such as the Globus Toolkit and e-Science because it frees them from the Grid security configuration [6, 11]. The emerging Grid technologies are leveraging the pains. However, the user is still responsible for loading her Web services efforts, and are guided by Open Grid Services certificate from a Grid-enabled host into a credential server, Architecture (OGSA) at the Global Grid Forum [29]. such as MyProxy, which stores the Grid users’ credentials. To realize the resource sharing across multiple domains, the From the user’s credentials, the MyProxy server derives underlying security infrastructure plays a key role. The short-lived proxy certificates [28] after receiving requests widely used Grid Security Infrastructure (GSI), first from Grid portals or other Grid-enabled applications [18]. integrated in Globus, provides secure communication, The configuration complexity is mirrored on the remote host. mutual authentication, and coarse-grained single sign-on The user will have to contact the system administrator for an (SSO) access to remote resources [7, 27]. It allows a user to account on the remote machine that she wants to use as a access her resources across administrative domains through computing resource. After being given an account with a the use of her proxy certificates, and by delegating her rights user name, she has to ask the Grid administrator to add the to remote agents that manage remote resources on the user’s mapping entry of her username and her certificate’s X.500 behalf. The assumption it is based on is that the user had an distinguished name (DN) into a gridmap file. At runtime, account on the remote host and the remote agent is able to GSI will authenticate the user and map her Grid identity to locate a mapping from the user's Grid identity to an the local account according to the gridmap file. In some associated local host account. This model has worked cases, the user may also be responsible for setting up a reasonably well for large, centrally coordinated Grids like separate hosting environment under that account. NASA's Information Power Grid [12] and NSF’s TeraGrid [3]. However, as the size and diversity of these research The administrators have the issue of maintaining an collaborations grow larger, it becomes increasingly difficult exploding number of user accounts, of which many will only be used for a short time, or never be used at all. As a result, a A and the document is signed by Y, the provider of significantly number of allocated resources is wasted in this service A. way. 2. The types of services that are provided to users in this infrastructure are Web and Grid services. For example, One of the identified problems is that, in its authorization the interface to remotely execute a specific application, process, GSI does not follow the principle of least authority or an interface to push or pull data from a specific (POLA), also known as the principle of least privilege. The stream, or an interface to see a directory of objects or gridmap file authorization model is coarse-grained, and in other services. It is never assumed that the user has an most cases allows the users and the user’s delegates more account on the computers upon which these remote rights than necessary for their jobs. As a consequence, the services execute. Remote services execute under the effect of compromises is more severe than needed [15]. identity of the service provider. Typically this service Authorization frameworks, such as the Community provider identity is the identity of the scientist or Authorization Service (CAS) [18, 19, 26], VOMS [1], engineer responsible for running or maintaining the Akenti [25], PERMIS [2] and PRIMA [14] provide a set of service on behalf of his collaborators. solutions to some of these problems. Their ability to manage 3. The entire infrastructure is built on a P2P chain-of-trust fine-grained access control can limit the risks. Nevertheless, model: The extend of the capability that I am willing to the resource providers are still required to account for the provide to an unknown remote user is limited by the identity and activities of each “user”. level of trust I have in providing access to that user. I demand that any user accessing my resource will present Peer-to-Peer (P2P) technologies, such as remote file-sharing a capability token signed by me and that the community systems, present us with another use-case for collaboration authority has authenticated the user that is presenting the at the other end of the spectrum. In these “Grids”, users capability. If the service that I am providing requires the provide resources and services to anonymous clients in use of other services to do its job, I am responsible for exchange for similar access from other users. The only assuring those service providers that the capability level security guarantee the service providers have is the vague that I provide to third parties is within the bounds of the assurance that the service they are providing is limited capability provided to me by them. access to network bandwidth and personal file space. With the problems and goals described, we will first 1.2 Goals and Accomplishments introduce the basis of the capability model in the following Given that many scientists and educators have access to section. Then we will discuss several existing authorization powerful desktop systems and small servers which they systems in Grids. In section 3, our capability-based control and are either open to the Internet, or can be made authorization infrastructure, XPOLA, will be presented in visible via a proxy server, it is natural to consider the both macroscopic and microscopic views. Next, the problem of running a user-level, peer-to-peer collaboration application of our capabilities framework is discussed as it Grid that allows a group of people to share access to a applies to our Web services framework, Grid services collection of research resources. Many collaboration framework, Grid portals, and application factory services. activities already operate in this manner, but they use ad-hoc Lastly, we will list a set of challenges and the corresponding security models. work to do in the second phase. This paper describes an extension to the Grid Security 2. THE CAPABILITY MODEL AND Infrastructure that exploits the convergence of Grid standards with Web services standards. It enables one to RELATED WORK IN GRIDS build peer-to-peer Grids with reasonable security and that 2.1 Access Control Matrix, ACL and are scalable and dynamic in structure. The goal of this work Capability is not only to provide a fine-grained authorization solution to The idea of capability originates from Dennis in 1965 [4]. A Web services in Grids, but also to hide the security issues capability is an identifier that carries a set of specific access from the regular Grid users as much as possible, and to give permission policies on the referred objects. the resource providers and administrators the flexibility and convenience to enforce and modify their authorization Resource 1 Resource 2 Resource 3 policies for the resources at runtime with minimal efforts. Alice Yes No No The systems we describe have the following characteristics: Bob Yes No Yes 1. Grid resources are made available to users through capabilities: signed tokens that allow specific users Carol No Yes No limited access to specific remote resources. These Table 1 An Access Control Matrix capability tokens can take the form of documents stating that user X has the rights to interact with service Illustrated in Table 1 is an access control matrix, which The Web and Grid services are loose-coupled, highly shows all the access rights of the users to a set of resources. distributed systems. The different clients and services may If we describe the table in the column order, we call it an be part of different trust domains without any initial trust access control list (ACL). For instance, the ACL of relationships. The process of trust establishment, unlike the “Resource 1” covers Alice and Bob, but not Carol. If we ones in the operating system level security, requires minimal describe the matrix by row, then each row holds the costs on communication as well as service load and maximal capabilities of a user. For example, the user Bob has the flexibility on authorization policy administration. The capabilities to access “Resource 1” and “Resource 3”, but capability model externalizes the authorization process from not “Resource 2”. A fine-grained authorization model may the service, and thus reduces a large portion of its load. choose either way when describing its access control policy For those reasons, many Grid deployments could benefit definitions. from the capability-based model. The fact that each Web Coupled with the principal of least privilege, the capability service has a standard definition document with all its model has the advantage over ACL in that it solves the operations, parameters, identifier, and location, allows one Confused Deputy problem, of which ACL is incapable, as to specify detailed authorization policies that could be proved by Hardy [10]. The “deputy” here is a program that is protected by cryptographic means. HP’s E-speak was the being executed on behalf of other programs or people with earliest capability-related effort on Web services [24]. appropriate permissions. The Confused Deputy problem Unfortunately, Lacking of commercial success, its happens when the program is somehow fooled to apply its development was halted in 2001. In the Grid community, permissions to something that it shouldn’t do. One of the authorization frameworks like CAS and VOMS, have also reasons is the “ambient authority” issue, which means the adopted a capability model explicitly or implicitly, as we program need not and cannot name the specific authority will discuss in section 2.3. that justifies the operations that it takes to sense or modify the world around it. 2.2 ACL-based Authorization Infrastructure in Grids An old example from the Confused Deputy problem is that a A cross-domain fine-grained authorization model usually printing program that audits the users’ printing activities by comprises of the nodes of clients, resources, and authorities. outputting the printing information to a log file, purposely, is In a typical ACL-based model, the authority is commonly on fooled to overwrite some important system file such as the resource side and part of the same administrative domain /etc/passwd, which leads to a security hole that allows as the resources. The resource provider often has no control attackers break in. The problem lies in the fact that the over the authority. In order to configure the authorization printing service works under two different authorities. One policy, the resource provider collaborates with the is representing the user to print his files; the other is for the administrators for the users. Usually this process is not system or system administrator to record users’ printing automated, can be cumbersome, and may involve many activities. Under each authority, it is able to do anything steps. more than what the user or the system administrator means. ACL does not solve the problem because if it looks up in the ACL, the program that is representing the administrator does Users Resource Authority have the authority to write /etc/passwd. However, in capability model, the deputy would have been given a set of capability tokens specifying what is allows to do with the Resource printing service and the logging file. Without being granted Provider the capability to write /etc/passwd, it will simply be denied Figure 1 ACL-based Authorization Infrastructure by the system. For now, we assume that the user has acquired her certificate The association of access control with objects can be and an account on the remote machine. After receiving a extended by defining a capability as the property of a user or client’s resource request, the resource node needs to verify process to carry out a particular operation. This concept was the client’s identity, after which it forwards the client’s first used in computer architectures such as the Cambridge identity to the authorization authority for an access decision CAP, the Hydra operating system for C.mmp, and the Intel concerning the targeted resource. This decision will either iAPX 432 architecture (see [13] for an excellent survey). permit or deny the client’s request. PERMIS and Akenti Capabilities have also been embedded in programming have adopted the ACL-model that works in the flow languages, such as E [16], and they seem to be especially illustrated in Figure 1 (note that Akenti can work in a important for distributed systems. Furthermore, capabilities capability-mode too). have been applied to the design and implementation of operating systems like EROS [21]. Within this ACL-based model, the resource node is explicitly responsible for authenticating and authorizing every single request. When the requests are repeated in a service authenticates the user with his X.509 certificate and sequential manner from the same client, the authentication issues capabilities to authorized users. On the resource and authorization processes are thus repeated, which makes server side, with the local policies, the resource provider still this system susceptible to scalability problems and possible makes the final authorization decision, even if the user has Denial of Service (DoS) attacks. Akenti uses caching to been given the permission by the CAS server. However, the mitigate the problem, but it hurts those isolated requests at resource server will allow no more than what the capability the same time. allows. 2.3 Capability-based Authorization Even though the CAS framework supports fine-grained Infrastructure in Grids authorization, resource providers have to verify that the Another category of fine-grained authorization frameworks CAS server is to be trusted and that the community's policies works with a capability model. In such infrastructures, the match their own local policies through some out-of-band client’s possession of a capability confers an access right to a form of configuration, which is not applicable in the case of resource, according to the pre-defined policy embedded in highly dynamic services like the impromptu experimental that capability. ones that are provided by the scientist users. The workflow is as follows: the user first sends a capability Moreover, any form of centralized administration presents a request to the authorization authority. The resource provider single point of failure when being compromised or under could either approve the request or delegate his rights to the attacks. One proposed solution of having multiple replicas authority to issue the requested capability tokens. of CAS servers to address the single-point-of-failure issue Subsequently, the client sends her access requests along will statistically bring more chances of being compromised. with the capability tokens to the resource node. On the Note that the capability model itself is not perfect either. resource node, the capability token’s integrity is first Capability revocation is a thorny problem in CAS as well as verified. The policy details of the capability are then any other capability-based systems. extracted as the reference to the final authorization decision. Other fine-grained Grid authorization infrastructures are Figure 2 shows a simplified diagram of the capability model. similar to CAS or Akenti. The different approaches can be distinguished in the way they bind policies to certificates Resource Users Resource and their authorities, while the enforcement mechanisms Provider may differ slightly. (Authority) Figure 2 Capability Authorization Infrastructure As we will show in the next section, XPOLA tries to keep Besides the advantages on solving the Confused Deputy the advantages of the capability model, while solving most problem and externalizing authorization administration as of the issues associated with the capability model and other we mentioned in section 2.1, the capability-based fine-grained authorization efforts. The main difference from authorization infrastructure also has the benefit of any other existing capability-based infrastructures including reusability. The issued capability tokens are reusable for CAS is its peer-to-peer administration model that securely multiple accesses as long as their policy allows. It saves the brings maximal freedom to scientists and researchers. In the repeated authorization evaluation processes that are extreme case that all services are provided by one single user inevitable in ACL-based systems. or a service account, that user becomes the administrator, just like the role in other infrastructures. A more practical reason is that some of the Grid users, especially those scientists, have the will to build their 3. XPOLA, THE MACROSCOPIC VIEW extemporaneous experiment services and allow others to use 3.1 The Big Picture them securely without the lengthy interference of their The name of XPOLA stands for an eXtensible fine-grained system or Grid administrators. Capability allows them to authorization infrastructure that strictly conforms to the distribute their services in a peer-to-peer fashion and remove Principle of Least Authority (POLA). The design picture of the system security concerns that hinder their research. XPOLA is shown in Figure 3. The capability manager CAS is an example of a capability-based authorization (Capman) is the platform for resource providers to service. In CAS, a user must present a capability issued by collaborate with their users. Through this platform, the user’s community’s authority to the resource provider to resource users send requests to the providers for access access the resource. The CAS capability token is bound to an rights; the provider processes the requests and creates the extended proxy credential. Instead of the resource provider corresponding capability tokens. The capability manager issuing the capability directly, the provider delegates part of stores the capability tokens and supports the providers with his authorities to a community administrator. Every the functionalities for manipulating the capabilities: community has at least one central administrator to define capability generation, destruction, update, renewal, request the authorization policies and manage the service. The processing, and optionally pushing the capabilities to the users. The registry service provides registration and discovery of which contain detailed authorization policy and protected by the available Web service instances. It keeps the information X’s signature. We will dissect the capability token later, but of all the registered service instances. Every time a new here we just need to know that the identity of Y is included in service is instantiated, it is supposed to register itself by the policy as one of the users. Now X advertises his service sending a Web Services Definition Language (WSDL) to Y, who will to use A. When Y tries to access A, his token document to the registry. A WSDL document contains the agent contacts the Capman service for the required detailed information needed to interact with the service capability token. If available, the token is fetched and sent instance. along with the service request to A, where the capability is to be verified. Thus the user Y is served by A, if the request If the capability of a specific resource for a specific user matches what the capability allows. exists in the capability manager’s storage, the user can fetch the capability from the manager directly and stores it in her 3.2 Attack Analysis local token agent. The token agent is an ssh-agent-like client Figure 3 can be simplified as Figure 4 to reflect the trust for interacting with the capability manager and caching the relationships between the main entities, namely the retrieved capability tokens. capability authority, the clients, the service instances, and an optional CIA service. Service Registry Provider (EPRservice A, …) Persistent CIA Storage Request create Processing Capability Community update Capability Manager Clients Services (Capman) Informative Authorities Capability Authority Request destroy Figure 4 A Simplified Trust Relationship Picture for Attack Analysis The service might be subject to various forms of illegal Token Agent Host accesses and attacks from the clients. Examples of illegal or Processing SVC malicious access attempts are: capability token Stack A 1. The user does not have a capability for the remote Service Requester resource, or has a fake or invalid capability. Figure 3 The Big Picture 2. The capability is valid, but the user applies it beyond its policy definition. For instance, the user tries to The Community Informative Authority (CIA) is an optional access some other resource that is not specified in the trusted authentication service for identity verification in the capability policy. community. It establishes trust relationships, either mutual or unilateral as required, between the users and providers. 3. The access is authorized, but the user orchestrates a Note that CIA service does not make any authorization Denial of Service attack (DoS) with the valid decisions for the providers. It is left to the providers capabilities. themselves to make their authorization decisions based on The first two situations can be handled easily by executing the provided authentication information. CIA is not the capability enforcement. The last one is a tricky problem necessary if two parties can mutual authenticate each other for capability-based systems. We need to revoke the by other means, for example, through the portal login malicious users’ capabilities at runtime while the DoS attack authentication of a trusted portal. No matter whether it takes place. works implicitly or explicitly, the CIA service is designed to The capability manager does not need much protection as address the trust bootstrap problem in an XPOLA-enabled the capability tokens are inherently protected by the Grid community. signatures from being forged or tampered. They are totally To make it better understood, let’s walk through one of the useless to any user who steals them, as the attackers’ use scenarios as a provider, X, of service A, and a service A’s identities are not specified in the policies, unless a valid user, Y. Suppose X first creates the service A on a remote user’s private key is available at the same time. host. Upon being created, the service A registers itself to a The worst case could happen is when the private key of a persistent registry. The provider then wants to distribute the provider is stolen; however we can confine the service to other people including the user Y. Through a consequences of this compromised authority to the provider Capman service, he generates a set of capability tokens himself, who is merely one of the non-privilege users. Note standards from W3C and OASIS for SOAP-based Web that the providers won’t be able to blame the administrators, services. The security related elements are added to the because they themselves are responsible for the security of header section of SOAP messages, including signatures, their own resources. XPOLA is flexible in that under some references, confirmation methods, canonicalization methods, circumstances, administrators can take over the etc. authorization work by running services with special non-privilege service accounts. 4. XPOLA, THE MICROSCOPIC VIEW SOAP Message 4.1 The Capability Tokens A capability is a policy definition referring to a specific Header resource object. In XPOLA, a policy definition comprises of a delegation relationship and a set of authorization decisions Capability Token for the referred object. The capability is protected with signatures and can be encrypted if needed. Policies Formally we define a capability as follows. Assume a resource provider named X creates a capability C to delegate Signature a set of rights R on the service identified as S to a group of users P after the time of T with the duration ∆t. The Web Service Security Section capability CX is defined as (Signature, public keys, …) C = [ X , P, R, S , T + ∆t ] XPOLA has adopted the Security Assertion Markup Body Language (SAML) to express C, but it could be any policy languages, as long as the recipient, who himself set up the Figure 5 A Capability Bound to a SOAP Message policy in most cases, is able to understand it. XPOLA is Similarly, capability tokens are embedded into the header extensible to use policy definitions expressed in different section of users’ SOAP messages, as showed in Figure 5. formats or languages. The SOAP message is then signed with the user’s private key and the generated signature inserted into the Web The policy definition for the operations of Web services is service security section to protect the integrity of the SOAP specified according to their Web Services Definition message, along with the user’s public key and identity, Language (WSDL) documents. The WSDL document is the which will be verified against the capability token later. standard interface description of a Web service. 4.2 The Capability Enforcement in Web The policy must contain the following items, corresponding to the formal definition: Services The enforcement is done when the capability-enabled ● Parameter X: One or a set of the resource providers’ SOAP message arrives at the remote resource service. We X.500 distinguished names (DN) from their X.509 will identify the actual resource owner as A*, the actual certificates. resource with the identifier S*, the actual resource access ● Parameter P: One or a group of specific users’ DNs. attempt E that happens at the time T*. The original capability CA arrives at the resource as ● Parameter R: A set of authorization decisions corresponding to the concerned operations of S. C ' = [ X ' , P' , R' , S ' , T '+ ∆t ' ] ● Parameter S: A service identifier, which is an endpoint The final authorization decision is made upon reference (EPR) of a specific Web service. ● Parameter T: The lifetime of the capability. C = C ' , X = X * , S = S * , E ⊆ R , T * < T + ∆t Furthermore, the assertion will include signatures and and verification methods. When privacy is a concern, the capability should be encrypted. ∏r ∑r ≥ F . j j∈C ,C ⊆ R ri ∈R i s ri ∈ R , ri ∈ {0,1} Within the Web services framework, when a user makes secure requests to remote resources, her client program Here, Fs is the authorization threshold of the resource S and communicates with them by exchanging SOAP messages Fs = 1. When ri = 0, it means “denied”; while ri = 1 means that comply with Web services security specifications. Web “granted”. The set C is the crucial authorization decisions services security is a series of emerging XML-based security in R, which means any element rj in the set C must be “granted”, in order that the access be authorized. The above 5. THE XPOLA IMPLEMENTATION AND process can be generalized as ri ∈ [0,1] and Fs ≥ 0 , when APPLICATIONS the provider is not so sure about his decision. 5.1 The Implementation In XPOLA-enabled Web services, when a user makes a The implementation work includes the development of the remote call from the client side, the client program first core package of capability tokens with an application performs a preliminary authorization check by matching the programming interface (API), the capability management capability policy with the SOAP body content and the user’s toolkits, and their applications. identity. If nothing violates the policy, it inserts the The capability’s policy core adopts the popular XML-based appropriate tokens into the SOAP header, including the security language, Security Assertion Markup Language signatures; otherwise, the client is refrained from invoking (SAML) to express policy definitions [31]. SAML addresses the request. three different use-cases. An arriving A dispatched SOAP Msg SOAP Msg 1. Single Sign-On. The ability of a user (or subject in SAML terms) to authenticate in one security domain and have that authentication respected in another domain. SOAP Sig Verification SOAP Sig Generation Authentication 2. Authorization. The ability to ask questions about and N Processing Node describe the authorization of an actor to access a resources. Valid? Fault Generation Y 3. Transactions. The ability to pass the authority to complete Token Verification Token Insertion a task from one security domain to another. Token Sig Valid? At its most basic level SAML is a language for making Authorization assertions about authentication, attributes, conditions and Owner/User Match? Processing Node authorization decisions. For example, an authentication N Fault Generation assertion typically takes the form “subject S was Policy Decision? authenticated by means M at time T.” Attributes are simply Expired? name-value pairs associated with facts about a subject. Other Authorization decisions take the form “It has been decided Processing Nodes that subject S is authorized to perform action A on resource R. Application Service SAML provides a simple protocol to ask questions like “What authorization assertions are available for this Figure 6 The Processing Stack on the Service Side subject?”, “What are the values associated with these On the resource side, when the Web service receives a attributes for this subject?”, “Is this subject allowed to remote call through a SOAP message, the processing node access this resource in the following manner?”. first authenticates it by checking the validity of the user’s signature against the whole message. If nothing is wrong, In SAML terms, each capability policy document is a the authorization processing node verifies the signature of standard SAML assertion. The capability tokens are signed the embedded capability token. It then does a series of with the provider’s private key. The public key is attached matching operations, such as the capability issuer’s DN and for verification. the actual resource provider’s DN, the actual caller’s DN XPOLA is designed with extensibility in mind. If needed, and the allowed users’ DNs, the operations specified in the we can plug-in other XML-based policy languages such as capability and the ones in the SOAP body. It also checks eXtensible Access Control Markup Language (XACML) whether the capability has expired against the time. At last, it [32], or eXtensible rights Markup Language (XrML) [33]. peels off the capability token and passes the rest of the The bottom line is, the provider can use any policy language SOAP message on to the next processing node. The detailed he wants as long as he understands his own policies. Neither diagram is showed in Figure 6. does XPOLA mandate the use of PKI to protect the The client side policy checking prevents those unauthorized capabilities. The provider may use symmetric keys to sign requests from reaching services and is able to prompt the capabilities, though in that case he needs some other appropriate error information immediately to the users. ways like Kerberos, to authenticate the users and assertions. Services thus need not waste their resources on processing XPOLA relies on XSUL to bind the capabilities to SOAP these requests. The capability checking at the service side is messages and to enforce the capability-based authorization. mainly for guarding services from malicious users who XSUL is a light-weighted SOAP engine and a general Web elude the provided authentic clients to send the invalid services framework [23]. Web service developers can write requests directly. Such attack scenarios are discussed in their own capability-enabled Web services with XSUL with section 3.2. limited effort. We have also integrated the XPOLA into GSX for building capability-enabled Grid services. GSX is an Open Grid Services Infrastructure (OGSI) [30] and Web Services Resource Framework (WSRF) –compliant [34] While the proxy certificate is valid, the portal can fetch it Grid service framework based on XSUL [20]. The when the proxy certificate's owner, the portal user, wants to capability-based Grid service was assigned as homework in invoke a remote Grid service through a Grid portlet. The a distributed computing class. Turning an insecure Grid proxy certificate goes along with the remote service call to service into a capability-enabled one, was so simple that few authenticate the user, according the gridmap mechanism. student ever complaint. The authorization steps, if available, are done in the ACL style, as shown in Figure 7. The fact that our capabilities are inherently protected by themselves, allows us to use alternative ways to distribute One example of a Grid portal is the GFac portlet that works them even through unprotected means. For example, the as the client of a GFac service. The GFac service is a resource provider can use email, shared file system or even Grid-enabled application factory service that encapsulates fax to deliver capabilities to the user. non-Web services, launches them on remote hosts at run time, and presents them as Web service instances [8]. GFac To help the user, we provide a portlet-based capability has been applied to launch complicated jobs remotely in the manager and token agent build on the core capability APIs. scientific domains of biology and meteorology. We believe a user-friendly human-computer interface is vital in any security infrastructure. Many security systems Originally, GFac was a typical non-capability-based Grid fail, commercially or technically, simply because the users service. After a GFac Bio service is launched remotely by its would not or could not follow the complicated rules. The provider, a Bio service user can access the service from the capability manager as an independent Web service that Grid portal by contacting the remote service with her proxy shares the same database is also available. certificate stored in her portal user context. On the remote host, her Grid identity is first mapped to a local account, 5.2 XPOLA in Grid Portals where the authorization decision lookup is done by the GFac Grid portals are becoming very important in Grid Bio service. With no choice, the GFac service provider has deployments. They provide Grid community with a user to delegate his authority to the administrator such that he can friendly and familiar web-based interface to access their pre-configure the gridmap file and the authorization service, Grid resources. A Grid portal is made up of a cluster of before allowing the designated users to access his service. customizable display units, called portlets. A dynamically generated web page in a Grid portal is the aggregation of a The XPOLA integration moves GFac’s authorization group of portlets in a personalized layout. The Grid portlets process to the external Grid portal and avoids the could act as the clients of the remote Grid services. administrator’s authority brokering. After launching the service, the provider creates capabilities with capability A Grid portal provides its own authentication mechanism manager portlet and stores them in portal user contexts. through portal accounts bound with the users’ proxy Later, when a portal user logs in, he can simply access the certificates. Both resource providers and users, as the portal remote Bio service resource through the portlet client. The users, share the same trusted portal context. portlet automatically fetches the required capabilities from the user’s context if they are available. The remote service User authorizes the user according to the capabilities it receives. proxy Proxy GFac certificate Provider User Manager Service GFac Bio Service capability Portlet Portlet Remote Capability Proxy GFac token GFac Bio Host Manager Manager Service Service proxy proxy certificate certificate Admin Portlet Portlet Portlet gridmap capability capability proxy proxy capability Grid Portal token token token certificate certificate Authorization capability Provider User Context Service Grid Portal token Figure 7 Authorization in an ACL-based Grid Portal User Context Traditionally, when a user logs into a Grid portal with her account, the portal requests a proxy certificate from a Figure 8 Authorization in an XPOLA-enabled Grid Portal credential server, such as the MyProxy server [17], which returns a proxy certificate under the request. Usually the Because Grid portal is a trusted domain for all users, it proxy certificate has a very short period of lifetime. The implicitly plays the role of CIA by authenticating users with portal server stores the proxy certificate in the user context. their portal accounts. Grid portal makes it possible to transparentize the authorization process to portal users, as 6. CHALLENGES AND FUTURE WORK illustrated in Figure 8. 6.1 Session-based Communication To summarize the scheme depicted in Figure 8: in a Performance is a big challenge in XML-based security capability-enabled GFac service, the provider first launches implementations. Fortunately there are often possible a Bio job remotely through a GFac portlet. Then he simply workarounds to address the high overhead of the XML creates a series of capability tokens for those authorized processing. The initial results of some informal tests, gives users with the capability manager portlet and stores them in an indication that a session-based communication may be a the user contexts. After that, he can invite the users who promising solution. With session-based protocols integrated have been endowed with the capabilities to use his service. in our communication stack, we expect them to lower the The authorized user logs into the portal and she will be able XML security processing overhead significantly. In the to access the remote Bio service with the capabilities second phase of our XPOLA work, we plan to implement a automatically fetched from her user context in the Grid session-based secure communication specification, based on portal; while as a naïve user, she may never know the WS-Trust, WS-SecureConversation, and on the existence of capabilities. implementation work that was previously done [5]. 5.3 Performance 6.2 Revocation The capability-based authorization infrastructure is efficient Revocation is a challenge for all capability-based systems. as it allows for the reuse of capabilities and user-level After the users acquire the capability, the provider does not administration. An authorization decision, once made, can have any effective approach to revoke it. In most be reused for multiple times. capability-based systems, a capability’s lifetime is so short that revocation is not practical, while the short lifetime may However, if we only look at the narrowest definition of also help limit the amount of damage in the case of performance, it takes about 1000 to 2000 mille-seconds for a compromise. roundtrip communication between a client and a service, as shown in Figure 9. As the number of invocations grows, we One possible solution that we are investigating is to tie the see a slightly better throughput, probably due to the internal capability to established sessions. This would allow us to optimization of Java Virtual Machine itself, but it still falls revoke a specific capability immediately, by simply in the same range. Considering the bulky SOAP header with invalidating the underlying session. security-related SAML assertions, signatures, and public keys, we are not too surprised about these observations. The 6.3 Denial of Service Mitigation reason seems to be a general problem of the Capability itself is a good mechanism for dealing with implementations on Web services security nowadays: the Denial of Service (DoS) attacks for providing fine-grained underlying XML-related operations and processing, authorization. One of the principals of DoS attack especially the canonicalization operations, are very prevention and mitigation is using the cost model – a client expensive [22]. has to pay proportionally to the amount of the accesses to a service. A capability can be regarded as a resource “currency note” to be used to pay for the service it refers to. Capability tokens also make it possible to load balance the authentication and authorization work to other machines. A more sophisticated method will be to issue or request for dynamic capability tokens in the situation of an overwhelmed service, which would match the session-based capability system design. 7. CONCLUSIONS In this paper, we introduced an efficient and user-friendly capability-based authorization infrastructure, XPOLA. It is based on user-level, peer-to-peer trust relationships, and used for building secure Web services and Grid services with the support of fine-grained authorization policy enforcement. We presented both microscopic and macroscopic views of XPOLA, and discussed its Figure 9 Throughputs of an XPOLA-enabled Web service applications. Lastly, we brought up some challenges and tentative solutions that are to be addressed in future work. 8. ACKNOWLEDGMENTS [13] H. Levy, Capability-based Computer Systems, Digital We would like to thank Gopi Kandaswamy, Aleksander Press, 1984, now available at Slominski, and Yogesh Simmhan for their discussions and http://www.cs.washington.edu/homes/levy/capabook/ collaboration on the integration work of the factory service, [14] M. Lorch, D. B. Adams, D. Kafura, M. S. Koneni, A. XSOAP and GSX. We also appreciate Markus Jakobsson Rathi, and S. Shah. The PRIMA System for Privilege for his invaluable suggestions to improve the paper. Management, Authorization and Enforcement in Grid Environments. Proceedings of the IEEE 4th 9. REFERENCES International Workshop on Grid Computing, 2003. [1] R. Alfieri, R. Cecchini, V. Ciaschini, L. dell'Agnello, A. Frohner, A. Gianoli, K. Lorentey, and F. Spataro. [15] K. Keahey, V. Welch. Fine-Grain Authorization for VOMS, an Authorization System for Virtual Resource Management in the Grid Environment. Organizations. In European Across Grids Conference, Proceedings of Grid2002 Workshop, 2002. February 2003. [16] M. Miller, M. Stiegler, Open Source Distributed [2] D. W. Chadwick and A. Otenko. The PERMIS X.509 Capabilities, http://www.erights.org/index.html. role based privilege management infrastructure, Future [17] J. Novotny, S. Tuecke, V. Welch. An Online Credential Generation Comp. Syst. 19(2), pp. 27-289, 2003. Repository for the Grid: MyProxy. Proceedings of the [3] C. Catlett. TeraGrid: A Primer. Tenth International Symposium on High Performance http://www.teragrid.org/about/TeraGrid-Primer-Sept-0 Distributed Computing (HPDC-10), IEEE Press, 2.pdf. August 2001. [4] J. B. Dennis and E. C. Van Horn. Programming [18] L. Pearlman, V. Welch, I. Foster, C. Kesselman, and S. Semantics For Multiprogrammed Computations. MIT Tuecke. A Community Authorization Service for Group Technical Report MIT/LCS/TR-23, 1965. Collaboration. Proceedings of the IEEE 3rd International Workshop on Policies for Distributed [5] L. Fang, S. Meder, O. Chevassut, and F. Siebenlist. Systems and Networks, 2002. Secure Password-based Authenticated Key Exchange for Web services. ACM Workshop on Secure Web [19] L. Pearlman, C. Kesselman, V. Welch, I. Foster, S. Services, Oct.29, 2004, Fairfax, VA. Tuecke,The Community Authorization Service: Status and Future, CHEP03, March 24-28, 2003, La Jolla, [6] I. Foster, C. Kesselman. Intl J. Supercomputer California Applications, 11(2):115-128, 1997. [20] Y. L. Simmhan, Grid Service Extensions, [7] I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke. A http://www.extreme.indiana.edu/xgws/GSX/ Security Architecture for Computational Grids. Proc. 5th ACM Conference on Computer and [21] J.S.Shapiro, J.M.Smith, and D. J. Farber. EROS: A Fast Communications Security Conference, pp. 83-92, 1998. Capability System. SOSP, 1999. [8] D. Gannon, S. Krishnan, L. Fang, G. Kandaswamy, Y. [22] S. Shirasuna, A. Slominski, L. Fang, and D. Gannon. Simmhan, and A. Slominski. On Building Parallel & Performance Comparison of Security Mechanisms for Grid Applications: Component Technology and Grid Services, the 5th IEEE/ACM International Distributed Services. In CLADE 2004, Challenges of Workshop on Grid Computing, Pittsburgh, Nov. 8, Large Applications in Distributed Environments. IEEE 2004. Computer Society Press, Jun 2004. [23] A. Slominski, M. Govindaraju, D. Gannon, and R. [9] D. Gannon et al. Building Grid Portal Applications Bramley. Design of an XML-based interoperable RMI from a Web Service Component Architecture, 2004. system: SoapRMI C++/Java 1.1. In Proceedings of the 2001 International Conference on Parallel and [10] N. Hardy. The Confused Deputy, Distributed Processing Techniques and Applications, http://www.cap-lore.com/CapTheory/ConfusedDeputy. Las Vegas, NV, Jun 2001 html. http://www.extreme.indiana.edu/xgws/xsoap/ [11] T. Hey and A. E. Trefethen. The UK e-Science Core [24] Spring, Buranarach, Schrubb, and Zatuchnaya. E-speak Programme and the Grid, Future Generation Revisited. Forum on Design Languages Sep 3-7, 2001, Computing Systems, Vol 18 page 1017, 2002. Lyon, France. [12] W. Johnson, D. Gannon, B. Nitzberg. Grid as [25] M. Thompson, et al. Certificate-based Access Control Production Computing Environments: The Engineering for Widely Distributed Resources. In Proc. 8th Usenix Aspects of NASA's Information Power Grid, HPDC Security Symposium. 1999. 1999. [26] V. Welch, R. Ananthakrishnan, S. Meder, L. Pearlman, F. Siebenlist, Use of SAML in the Community Authorization Service, [30] Open Grid Services Infrastructure, OGSI working http://www.globus.org/security/CAS/Papers/SAML%2 group at Global Grid Forum (GGF) 0Feedback-aug19.pdf [31] OASIS, Assertions and Protocol for the OASIS Security [27] V. Welch, F. Siebenlist, I. Foster, J. Bresnahan, K. Assertion Markup Language (SAML) V1.1 Czajkowski, J. Gawor, C. Kesselman, S. Meder, L. http://www.oasis-open.org/committees/download.php/ Pearlman, S. Tuecke. Security for Grid Services, 3406/oasis-sstc-saml-core-1.1.pdf Twelfth International Symposium on High Performance [32] OASIS, Core Specification: eXtensible Access Control Distributed Computing (HPDC-12), IEEE Press, June Markup Language (XACML) V2.0 2003. http://docs.oasis-open.org/xacml/access_control-xacml [28] V. Welch, I. Foster, C. Kesselman, O. Mulmo, L. -2_0-core-spec-cd-02.pdf Pearlman, S. Tuecke, J. Gawor, S. Meder, F. Siebenlist. [33] ContentGuard, eXtensible Rights Markup Language X.509 Proxy Certificates for Dynamic Delegation. 3rd (XrML) 2.0 http://www.xrml.org Annual PKI R&D Workshop, 2004. [34] OASIS, “Web Service Resource Framework”, March [29] Open Grid Services Architecture, OGSA working 2004. group at Global Grid Forum (GGF), https://forge.gridforum.org/projects/ogsa-wg XPOLA—An Extensible Capability-based Authorization Infrastructure for Grids Liang Fang, Dennis Gannon Indiana University Frank Siebenlist Argonne National Laboratory Outline • The Grid security • The problems to be solved • XPOLA – Macroscopic view – Microscopic view – User’s view • Challenges and future work • Conclusion 08/01/17 PKI R&D 05 2 The Grid OGSA 1997 2002 2004 Pre-Web services era (SOAP-based) Web services era Grid service = Web service + OGSA 08/01/17 PKI R&D 05 3 Grid Security Infrastructure (GSI) • GSI adopts public key cryptography as the basis to provide the Grid three main functionalities: – Secure communication: SSL, WS Security – Mutual authentication: PKI – Delegation: proxy certificate • Authorization (& Authentication): – A gatekeeper daemon maps a Grid identity to a local account at run time according to a gridmap file. – The Grid identity is allowed to do all the account’s rights. 08/01/17 PKI R&D 05 4 A Grid User’s Odyssey • Alice wants to access a Grid service. Unfortunately, she has to … Account ~3days Certificate ~1wk Grid-map ~0.5 day Application Application Registration (Learn how to) Manage her X.509 cert (Learn how to) (Learn how to) Finally, Time ~1day Configure ~0.5 hr Get her Grid to use the Her Service proxy cert ~0.5 day Grid service. Environment ready 08/01/17 PKI R&D 05 5 The Authorization Problems in Real Grid Applications • Inscalable in administration and maintenance – Host accounts – X.509 certificates • Coarse-grained authorization – An authorized user can do much more than accessing a service • For example, in Linked Environments for Atmospheric D iscovery (LEAD) project – How to provide the authorization to meteorological Grid servic es running on TeraGrid to THOUSANDS of scientists and grade s chool students? – Only a few privileged UNIX accounts available. – Grid services could be dynamically generated (by workflow eng ines as well as individual scientists). – Of course, no security breach is acceptable . 08/01/17 PKI R&D 05 6 Existing Grid Security Solutions to Fine- grained Authorization • ACL Model R1 R2 R3 – Akenti, Shibboleth, PERMIS Alice x • Capability Model Bob x x x – CAS, VOMS, PRIMA • Why we need XPOLA Carol x The Access Control Matrix – The above (was) not address ing general Web/Grid servic es in compliant with Web se Client 1 Resource 2 Authority rvices security specs. – With central admins, most o The ACL Model f them do not address dynamic services well. 1 2 Authority Client Resource 08/01/17 PKI R&D 05 7 The Capability Model XPOLA: The Characteristics • Principle of Least Authority/Privilege (POLA)-compliant: Strictly fine-grained authorization. • Scalable in administration and maintenance: It is never assumed that the service user has an account on the machines. The infrastructure is built on a Peer-to-peer chain-of-trust model. No central administrator involved. • WS-Security Compliant: Conforms to WS-Security for both persistent and transient Web/Grid services. • Extensible: PKI and SAML-based, but allows other alternatives. • Dynamic and Reusable: Grid resources (Web services and Grid services) are made available to users through manually or automatically generated capabilities, which can be used for multiple requests in their valid lifetimes. 08/01/17 PKI R&D 05 8 XPOLA: The Big Picture Service Provider Persistent Storage Request create Processing Capability Community Registry update Manager (EPRservice A, …) (Capman) Informative Capability Authority Request destroy Token Agent Host Processing SVC capability token Stack A Service Requester 08/01/17 PKI R&D 05 9 XPOLA: Capabilities • A capability includes: – Policy Document • Bindings of the provider’s distinguished name (DN), as well as the user s’ DNs. • Identifier of the Grid resource. – Optional: operations of a Web service instance • Life time (notbefore, notafter) – The provider’s signature generated with his private key. • Security Assertion Markup Language (SAML): • Each capability is a set of SAML assertions • AuthorizationDecisionStatement • However the policy document and protection mechanism c an be extensible: XACML, symmetric keys, … 08/01/17 PKI R&D 05 10 XPOLA: Web Services Security • Web services security • SOAP Binding – A series of emerging XML- based security standards SOAP Message from W3C and OASIS for SOAP-based Web services, Header to provide authentication, integrity, confidentiality Capability Token and so on. • XSOAP conforms to Web Policies (SAML Assertions) services security. Provider’s Signature WS Security Section (User’s Signature, …) 08/01/17 PKI R&D 05 Body 11 XPOLA: Enforcement An arriving A dispatched SOAP Msg SOAP Msg SOAP Sig Verification SOAP Sig Generation Authentication N Processing Node Valid? Fault Generation Y Token Verification Token Insertion Token Sig Valid? Authorization Owner/User Match? Processing Node N Fault Generation Policy Decision? Expired? Other Processing Nodes Application Service 08/01/17 PKI R&D 05 12 XPOLA: User’s View in Grid Portals Provider User capability Capability Proxy Weather token Weather Manager Manager Service Service Portlet Portlet Portlet capability capability proxy proxy capability token token certificate certificate token capability Grid Portal token User Context 08/01/17 PKI R&D 05 13 Challenges and Future Work • Revocation • Performance and Scalability – Message level session-based communication – Load balancing • Denial of Service (DoS) Mitigation 08/01/17 PKI R&D 05 14 Conclusion • XPOLA provides fine-grained authorization infrastructure to general Web and Grid services. • More than that – It scales – Extensible – WS-Security compliant – Adaptable for dynamic services – Reusable – User (as well as provider) friendly 08/01/17 PKI R&D 05 15 Shib-SAML & InCommon-Federal eAuthentication: Ken Klingenstein Director, Internet2 Middleware and Security Topics ƒ The basic ingredients • Shibboleth and SAML • Federations and InCommon, a US R&E federation • The Federal e-Authentication Initiative ƒ Interactions • Phase 1/2 – Certifying Shib, Shaping Policy Issues, etc • Phase 3/4 – SAML 2.0 Profile, USperson deliverables, interfederation peering ƒ Related activities • Work with Microsoft • International federations SAML ƒ Security Access Markup Language – an OASIS standard ƒ SAML 1.0 current eAuth standard; SAML 1.1 widely embedded ƒ SAML 2.0 recently ratified by OASIS earlier this year • Combines much of the intellectual contributions of the Liberty Alliance with materials from the Shibboleth community – a fusion product • Scott Cantor of Ohio State was the technical editor • Adds some interesting new capabilities, eg. privacy-preservation, actively linked identities • Possibly a plateau product Shibboleth ƒ An architecture, consisting of both a payload definition (using SAML) of attributes and a set of privacy-preserving methods of exchanging such payloads. ƒ A project that has managed the development of the architecture and code ƒ A code package, running on a variety of systems, that implements the architecture. ƒ (Note that other code sets are under development) Shib Timeline ƒ Project formation - Feb 2000 ƒ Inception of SAML effort in OASIS – December 2000 ƒ OpenSAML release – July 2002 ƒ Shib v1.0 April 2003 ƒ Shib v1.2 April 2004 ƒ Shib v1.3 April 2005 – non web services, e-Auth certified, ƒ Shib v1.3.x WS-Fed compliant ƒ OpenSAML 2.0 – relatively soon, we hope ƒ Refactored Shib 2.0 – 4Q05? Shibboleth-enriched Applications ƒ Via a web browser • Rich access to content providers, including Elsevier, OCLC, Napster, JSTOR, ArtStor, ExLibris etc… • Access to services such as WebAssign, Scholarsworkbench, HigherMarkets, etc. • Blackboard and WebCT ƒ Embedded in applications • Lionshare, Fedora • Globus and Grids • Darwin streaming video server, ArtStor Java client • Sympa list proc ƒ Still more at http://shibboleth.internet2.edu/seas.html ƒ Note that applications can obtain identity via a number of identifiers – ePPN, ePTargetedId, etc. Federations ƒ Persistent enterprise-centric trust facilitators ƒ Sector-based, nationally-oriented ƒ Federated operator handles enterprise I/A, management of centralized metadata operations ƒ Members of federation exchange SAML assertions bi- laterally using a federated set of attributes ƒ Members of federation determine what to trust and for what purposes on an application level basis ƒ Steering group sets policy and operational direction ƒ Note the “discovery” of widespread internal federations Federations and PKI ƒ The rough differences are payload format (SAML vs X.509) and typical length of validity of assertion (real-time vs long-term) ƒ Federations use enterprise-oriented PKI heavily and make end-user PKI both more attractive and more tractable – adding privacy (secrecy), ease of verification, addition of role, etc. ƒ The analytic framework (evaluation methodologies for risk in applications and strength of credentials) and infrastructure developed for PKI is useful for federations. ƒ The same entity can offer both federation and PKI services Shibboleth based Federations ƒ In the US • InQueue – several hundred enterprises globally in development, testing (and a little production) • InCommon – 12-15 institutions and partners in production service and posted operational practices • State and system federations beginning ƒ Internationally • Full production federations in Switzerland, Finland, United Kingdom, etc. • “League of federations” has been established to address development and peering InCommon federation ƒ Federation operations – Internet2 ƒ Federating software – Shibboleth 1.2 and above ƒ Federation data schema - eduPerson200210 or later and eduOrg200210 or later ƒ Federated approach to security and privacy, with policies posted by members in common formats ƒ Became fully operational 9/04; currently around 15 members ƒ Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon; approximately 150 members ƒ http://www.incommonfederation.org InCommon Members 4/10/05 Dartmouth College Elsevier ScienceDirect Cornell University Internet2 OCLC OhioLink - The Ohio Library and Information Network The Ohio State University Penn State SUNY Buffalo University of California, Irvine University of California, Los Angeles University of California, Office of the President University of California, San Diego University of Rochester University of Southern California University of Washington InCommon Uses ƒ Institutional users acquiring content from popular providers (Napster, etc.) and academic providers (Elsevier, JSTOR, EBSCO, Pro-Quest, etc.) ƒ Institutions working with outsourced service providers, e.g. grading services, scheduling systems, software sales ƒ Inter-institutional collaborations, including shared courses and students, research computing sharing, etc. ƒ (Shared network security monitoring, interactions between students and federal applications, peering with international activities, etc.) InCommon pricing ƒ Goals • Cost recovery • Manage federation “stress points” ƒ Prices • Application Fee: $700 (largely enterprise I/A, db) • Yearly Fee – Higher Ed participant: $1000 per identity management system – Sponsored participant: $1000 – All participants: 20 Resourceproviderids included; additional resourceproviderids available at $50 each per year, available in bundles of 20 InCommon Management ƒ Operational services by I2 • Member services • Backroom (CA, WAYF service, etc.) ƒ Governance • Steering Committee – drawn from CIO level leadership in the community - sets policies, priorities, etc. • Project manager – Internet2 ƒ Contractual and policy issues were not easy and will evolve ƒ Initially a LLC; likely to take 501(c)3 status in the long term Trust in InCommon - initial ƒ Members trust the federated operators to perform its activities well • The operator (Internet2) posts its procedures • Enterprises read the procedures and decide if they want to become members • Contracts address operational and legal issues ƒ Origins and targets establish trust bilaterally in out-of-band or no- band arrangements (using shared posting of practices) • Origins must trust targets dispose of attributes properly • Targets must trust origins to provide attributes accurately • Risks and liabilities managed by end enterprises, in separate ways – Collaborative apps are generally approved within the federation – Higher risk apps address issues through contractual and legal means Members trust InCommon operations ƒ The federation operations presents limited but real exposures in identity proofing members properly and in the metadata management ƒ InCommon publishes its procedures for identity proofing and its operational procedures • InCommon CA CP/CPS • Metadata management process ƒ Individual enterprises read the policies and decide whether to trust the federation operations and how to assign liability FOPS 2: InCommon CA Ops ƒ CA_Disaster_Recovery_Procedure_ver_0.14 • An outline of the procedures to be used if there is a disaster with the CA. ƒ cspguide • Manual of the CA software planning to use. ƒ InCommon_CA_Audit_Log_ver_0.31 • Proposed details for logging related to the CA. ƒ Internet2_InCommon_CA_Disaster_Recovery_from_root_key_compro mise_ver_0.2 • An outline of the procedures to be used if there is a root key compromise with the CA. ƒ Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61 • Draft of the PKI-Lite CPS. ƒ Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21 • Draft of the PKI-Lite CP. ƒ Internet2_InCommon_Certificate_Authority_for_the_InCommon_Federa tion_System_Technical_Reference_ver_0.41 • Document describing the CA. Members Trusting Each Other: Participant Operational Practice Statement ƒ Basic Campus identity management practices in a short, structured presentation • Identity proofing, credential delivery and repeated authn • Provisioning of enterprise-wide attributes, including entitlements and privileges ƒ Basic privacy management policies • Standard privacy plus • Received attribute management and disposal ƒ No audit, unclear visibility of policies InCommon Progress ƒ Relatively straightforward • Syntax and semantics of exchanged attributes (Eduperson) • Set up and operation of federation • Selling the concept and value ƒ More challenging • Having applications make intelligent use of federated identity • Handling indemnification • Finding scalable paths for LOA components Federal eAuthentication ƒ Key driver for e-government, operating under the auspices of GSA ƒ Leveraging key NIST guidelines ƒ Setting the standard for a variety of federated identity requirements • Identity proofing • SAML bindings • Credential assessment • Risk assessment ƒ Technical components driven through the InterOp Lab ƒ http://www.cio.gov/eAuthentication/ eAuthentication Key Concepts ƒ Approved technologies ƒ Credential assessment framework ƒ Trusted credential service providers Federal eAuthentication federation ƒ Original model was to certify a few key Credential Service Providers (CSP’s) to a variety of federal applications, both agency to agency and citizen to agency ƒ Evolving model includes a federation of federal agencies, peering with other sector-based federations ƒ Peering is intended to leverage other peering vehicles for trust ƒ Peering could also include operational components such as attribute and identifier mappings, and correlation of contractual and financial approaches Phase 1/2 of Interaction ƒ Phase 1/2 work commissioned to identify issues and opportunities for interactions between higher ed and federal eAuthentication ƒ Deliverables include • Policy framework comparison submitted Oct 7 • Technical interop of Shib demonstrated October 14 • CAF/POP comparison submitted Jan 28 • Next stages scope of work submitted mid-Feb Phase 3/4 of the Interactions ƒ Deliverables include: • Recommended e-Authentication SAML 2.0 profile. • Recommendations concerning a USperson object class • Recommendations on the formation of a US Government federation • Draft approach to interfederation peering ƒ Deliverables due Sept 30, 2005 Interfederation Peering ƒ New territory… ƒ Technical • Mapping LOA’s • Mapping attributes • SAML technical issues • PKI technical issues ƒ Policy • What agreements need to be in place • Where does liability flow • What audit requirements will be needed USPerson ƒ Initial focus is on citizen-agency interactions ƒ Extensible architecture; likely a UML model with various bindings ƒ Intended for use by CSP’s, either directly, via peering mappings, etc. ƒ Deliverables may include a small core of attributes, organizational superstructure, discussions on mechanisms for extensions, maintenance, authoritative sources, etc. ƒ WACOW International federation peering ƒ Shibboleth-based federations in the UK, Netherlands, Finland, Switzerland, Australia, Spain, and others ƒ International peering meeting October 14-15 in Upper Slaughter, England ƒ Issues include agreeing on policy framework, comparing policies, correlating app usage to trust level, aligning privacy needs, working with multinational service providers, scaling the WAYF function ƒ Leading trust to Slaughter… Upper Slaughter Three types of issues ƒ Internal federation issues • Business drivers – educational, research, admin – helping each country find a reason • Cookbook – key issues and common touchpoints • Alignment with other trust services such as PKI ƒ Inter-federation issues • Needs for agreements – Authncontext, attributes • Needs for legal frameworks – Assignment of roles within federation between – Treaties/MOU between federations • Privacy ƒ Union of federations issues (brand, membership, etc..) Immediate International Issues ƒ “International WAYF” – management of the user experience • List of Federations that contain IdP’s • Where to put multi-nationals? • Handling of exceptions in a consistent fashion ƒ Privacy • EU Privacy directives intended for attributes associated with identity • Rules for interior and exterior privacy may be different for EU • And then there’s the Swiss… WS-Fed and Shib ƒ Agreements to build WS-Fed interoperability into Shib • Contracts signed; work to begin later this spring • WS-Federation + Passive Requestor Profile + Passive Requestor Interoperability Profile ƒ Discussions broached, by Microsoft, in building Shib interoperabilty into WS-Fed; no further discussions ƒ Devils in the details • Can WS-Fed-based SPs work in InCommon without having to muck up federation metadata with WS-Fed-specifics? • All the stuff besides WS-Fed in the WS-* stack Next Steps ƒ The GUI’s and the diagnostics ƒ Getting the applications enabled ƒ Building the federations ƒ Federation peering ƒ Federated network security ƒ Use with virtual organizations ƒ Federated authorization International and Bridge-to- Bridge PKI Interoperability: Update Peter Alterman, Ph.D. Chair, Federal PKI Policy Authority Goal z To create a ubiquitous, global, trustworthy and secure digital infrastructure, which respects individual privacy needs, to support e-commerce and e-government. 4th Annual PKI R&D Workshop 1 Activities at Federal PKI z International PKI cross-certifications z Bridge-to-Bridge cross-certification 4th Annual PKI R&D Workshop International PKI Cross- Certifications z U.S. Federal Bridge and Government of Canada - pending program application z U.S. Federal Bridge and Australia Gatekeeper - pending completion of new Gatekeeper policy z U.S. DOD PKI and Trusted Allies z Others – German Business Bridge, for example 4th Annual PKI R&D Workshop 2 Bridge to Bridge Work z International Collaborative Identity Management Forum – B2B WG z FBCA – HEBCA ongoing prototype interoperability with draft revision of FBCA CP on the table 4th Annual PKI R&D Workshop Bridges Playing z FBCA (US Federal) z HEBCA (US Higher Ed) z SAFE (International Pharmaceutical) z Proposed Aerospace (International Military/Civilian) 4th Annual PKI R&D Workshop 3 Issues to be Resolved z Citizenship of trusted CA operators z Audit standards and requirements z Technical interoperability issues z Path discovery/path validation z Exclusion trees that work and work through bridges z Transitive trust 4th Annual PKI R&D Workshop Contact Information z altermap@mail.nih.gov 4th Annual PKI R&D Workshop 4 Higher Education Bridge Certificate Authority (HEBCA) and the NIH- EDUCAUSE PKI Interoperability Pilot Phase 4 NIST PKI R&D Workshop #4, April 2005 • Contents – Introduction – HEBCA Project • Overview • Progress – PKI Interoperability Pilot • Overview • Progress – Summary • Conclusions • Questions 2 HEBCA & the PKI Interoperability Pilot • What are they? – The HEBCA Project being undertaken by Dartmouth College includes all activities related to the instantiation and operation of a production-level Public Key Infrastructure (PKI) Bridge Certificate Authority catering to the US Higher Education community. – The PKI Interoperability Pilot being undertaken by NIH and various federal and US Higher Education participants under the direction of the Federal PKI Steering Committee is aimed at developing models and the technology necessary to allow locally- issued digital certificates to be used to sign digital versions of government or higher education forms, and for the Federal Government or Higher Education Institutions to be able to trust and validate those signatures and corresponding certificates. 3 HEBCA & the PKI Interoperability Pilot • What is the value presented by these initiatives? – HEBCA facilitates a trust fabric across all of US Higher Education so that credentials issued by participating institutions can be used (and trusted) globally e.g. signed and/or encrypted email, digitally signed documents (paperless office), etc can all be trusted inter-institutionally and not just intra-institutionally – Extensions to the Higher Education trust infrastructure into external federations is also possible and proof of concept work with the FBCA (via BCA cross- certification) has demonstrated this inter-federation trust extension – The interoperability pilot is a model for end-to-end paperless transactions and portions of the model are being adopted currently in Federal government and industry applications. The paperless office has well documented savings in time, effort and material costs for those organizations implementing them (NOTE: GPEA requires this). – Potential for stronger authentication and possibly authorization of participants in grid based applications – Contributions provided to the Path Validation and Path Discovery development efforts – Facilitates compliance with legal requirements (GPEA, HIPAA) 4 HEBCA Project - Overview • Higher Education Bridge Certificate Authority – HEBCA • Modeled on FBCA • Began December 2002 • Prototype created at Mitretek, now hosted at Dartmouth College 5 HEBCA Project - Overview • What will it provide? – The HEBCA Project will create and maintain three new Certificate Authority (CA) systems for EDUCAUSE and will also house the existing HEBCA Prototype CA – The three CA systems to be created are: • HEBCA Test CA • HEBCA Development CA • HEBCA Production CA – The HEBCAs will be used to cross-certify Higher Education PKI trust anchors to create a bridged trust network – The HEBCA Test CA will also be cross-certified with the Prototype FBCA (other emerging Bridge CAs are also targets) and the HEBCA production CAs will be cross-certified with the production FBCA. 6 HEBCA Project - Overview • What will it look like? (Artists impression only) 7 HEBCA Project - Overview FBCA PA and CP oversite HEBCA PA and CP oversite FBCA Infrastructure CA HEBCA CA Infrastructure Root Root Cert Cert FBCA HEBCA Directory Directory Root Cross Cross Cross Cross Cert Cross Cross Cross Cross CertPair CertPair CertPair CertPair CRLs CertPair CertPair CertPair CertPair X.500 DSP Protocol Root (Chaining Cert Agreements) between CRLs FBCA and Cross Certified PKI provider ROD FBCA University 1 University 2 Referral Referral Referral Other Cross HEBCA PKI DST ACES PKI FBCA PKI University 1 PKI University 2 PKI Certified PKI Other Cross Other Cross CA CA CA CA CA CA Certified PKIs Certified PKIs Root Root Root Root Root Root Cert Cert Cert Cert Cert Cert Border Dir Border Dir Border Dir Border Dir Border Dir Border Dir Cross Cross Cross Cross Cross Cross CertPair CertPair CertPair CertPair CertPair CertPair CRLs CRLs CRLs CRLs CRLs CRLs LDAP Based Directory X.500 Based Directory Utilizing the Registry of Directories Directories Interconnect via Chaining (X.500 DSP) Utilizing LDAP Referrals 8 Proposed CA-2 CA-1 Inter-federations CA-n Wisconsin FBCA Dartmouth Cross-cert Texas DST NIH HEBCA ACES UVA Cross-certs Univ-N USHER Aero SAFE 9 HEBCA Project - Overview • Organization 10 HEBCA Project - Overview • EDUCAUSE • HEPKI Council – EDUCAUSE is a nonprofit association – The Higher Education Public Key whose mission is to advance higher education by promoting the intelligent Infrastructure (HEPKI) Council is an use of information technology. advisory body to EDUCAUSE. The – Membership is open to institutions of HEPKI Council activities include… higher education, corporations serving • oversee activities in support of the higher education information operational PKI services in the technology market, and other related interests of U.S. higher education and associations and organizations. Resources include professional research development activities; print and • oversee activities of the HEBCA PA electronic publications, including including reviewing the business books, monographs, and magazines; plans, operations, and other activities strategic policy advocacy; teaching and of the HEBCA PA learning initiatives; applied research; and extensive online information • report periodically to EDUCAUSE. services. • the HEPKI Council appoints one – The current membership comprises voting member of the HEBCA PA. more than 1,900 colleges, universities, and educational organizations, including 200 corporations, with 15,000 active members. 11 HEBCA Project - Overview • Policy Authority • Policy Authority Members – The HEBCA PA establishes policy for and – The Policy Authority has seven voting oversees operation of the HEBCA. members. HEBCA PA activities include… • One represents the HEPKI Council. • approve and certify the Certificate Policy • The other six represent the HEBCA (CP) and Certification Practices Statement Membership. (CPS) for the HEBCA • Five of the initial HEBCA Membership PA • set policy for accepting applications for members come from each of the HEBCA cross-certification and interoperation with Charter organizations the HEBCA – Dartmouth College – Duke University • certify the mapping of policy between the – The University of Alabama at Birmingham HEBCA CP and applicants’ CP’s – The University of California Office of the • establish any needed constraints in cross- President certification documents – The University of Wisconsin at Madison • represent the HEBCA in establishing its • The final HEBCA Membership own cross-certification with other PKI representative is chosen by majority vote of bridges the initial 5. • set policy governing operation of the • HEBCA Membership is open to HEBCA representatives from the initial 5 Charter • oversee the HEBCA Operational Authority institutions and any other institution that • keep the HEBCA Membership and the cross-certifies with the HEBCA. HEPKI Council informed of its decisions and activities. 12 HEBCA Project - Overview • HEBCA Operating Authority – The HEBCA OA is the organization that is responsible for the issuance of HEBCA certificates when so directed by the HEBCA PA, the posting of those certificates and any Certificate Revocation Lists (CRLs) or Certificate Authority Revocation Lists (CARLs) into the HEBCA repository, and maintaining the continued availability of the repository to all parties relying on HEBCA certificates. – Specific responsibilities of the HEBCA OA include: • Management and operation of the HEBCA infrastructure; • Management of the registration process; • Completion of the applicant identification and authentication process; and • Complying with all requirements and representations of the Certificate Policy. – Key personnel from the Dartmouth PKI Laboratory were chosen as the HEBCA Operating Authority by the HEBCA PA under the direction of EDUCAUSE (the project sponsor). – Scott Rea is the Director of the HEBCA OA and the designated OA Administrator in accordance with the HEBCA CP. 13 HEBCA Project - Progress • What’s been done so far? – Operational Authority (OA) contractor engaged (Dartmouth PKI Lab) – MOA with commercial vendor for infrastructure hardware (Sun) – MOA with commercial vendor for CA software and licenses (RSA) – Policy Authority formed – Prototype HEBCA operational and cross-certified with the Prototype FBCA (new Prototype instantiated by HEBCA OA) – Prototype Registry of Directories (RoD) deployed at Dartmouth – Draft of Production HEBCA CP produced – Draft of Production HEBCA CPS produced – Preliminary Policy Mapping completed with FBCA – Test HEBCA CA deployed and cross-certified with the Prototype FBCA – Test HEBCA RoD deployed – Production HEBCA development phase underway – Infrastructure has passed interoperability testing with FBCA 14 HEBCA Project - Progress • Projected Milestones – Deployment phase complete by 7/31/05 • Cross-certify all Existing HE Domain CAs with Test CA by 5/31/05 • HEBCA Production CA operational by 7/1/05 – Cross-certification with FBCA by 7/31/05 • Start HE Domain CAs cross-certification with HEBCA Production CA by 8/1/05 – Post Operation Start Activities • Other Bridge cross-certifications • Improvements to system • Improved Test bed for Bridge-aware applications 15 PKI Interoperability Pilot - Overview • NIH-EDUCAUSE PKI Interoperability Pilot • Funded by the Federal PKI Steering Committee • Began February 2002 • Hosted at NIH (CAM & NRS) and relies on HEBCA now hosted at Dartmouth College 16 PKI Interoperability Pilot - Overview • What does it do? – Ability for faculty and staff at academic institutions to download, complete, digital signing (multiple digital signatures if required), and send XML forms to US Government or other institutions • NOTE: Prior phases of this project used desktop signing applications from e-Lock to sign Microsoft office documents • NOTE2: The current process facilitates signing any file type through attachment of supporting documents which are base64 encoded and submitted as an element in the XML D-Sig standard output – Automated receipt (signed if required) to submitter – NARA requirements met for audit logs – Certificate path discovery and validation infrastructure with resolution of multiple certificate configuration and directory interoperability issues – Operational PKI bridge pathway between prototype of the FBCA and prototype of the HEBCA, which is funded and operated by EDUCAUSE • This will be upgraded to production systems once the Production HEBCA is online – expected mid 2005 17 PKI Interoperability Pilot - Overview • Why do this? – Universities and colleges are adopting digital signature technology for many reasons. Similarly, Federal Agencies are also adopting digital certificates. It is vital that electronic credentials be reusable. – The project enables secure electronic forms-based transactions among diverse, unaffiliated business partners (including, but not limited to, the Federal Government) – Project is universally applicable for all forms-based business transactions requiring one or more signatures 18 PKI Interoperability Pilot - Overview • What does it look like? 19 PKI Interoperability Pilot - Overview Application Flow Public DMZ Secure Remote CA Applicant Email Server OCSP CAM Archive Database SSL/WEB Directory Co-signer Server ACL Database 20 PKI Interoperability Pilot - Overview Validation Engine NIH CAM Room: 2 Path cache Path 1 Path 3 HEBCA NIH others FBCA Validation cache Trusted CAs cross cross cross Trans 1 cert pr cert pr cross cert pr Trans 2 1. Certificate submitted to cert prcross c Trans 3 3 cert pr cross CRL cache CAM CRL CARL cert pr CRL CARL CRL CARL 4 2. Based on Trust Anchor CAM accesses the FBCA HEBCA FBCA University 1 University 2 University 3 others 3. At FBCA find a Cross cross cert pr cross cert pr cross cert pr cross cert pr cross cert prcross 1 Certificate to HEBCA CARL cert prcross cert pr CRL 4. Cross Certificate points 5 6 NIH Submission App NIH Application to the HEBCA RoD FBCA Referraal University 1 Referral University 2 Referral University 3 Referral ..... University 2 Signed 5. At HEBCA find a Cross SF424 Certificate to University 7 c c 2 PKI University 1 University 2 University 3 6. Return LDAP referral to cross cross cross cert pr cert pr cert pr the CAM CRL CRL CRL CARL CARL CARL 7. CAM directly follow the referral to University 2 information 21 PKI Interoperability Pilot - Progress • Accomplishments: • a certificate path discovery and validation infrastructure for assessing the legitimacy of digital certificates issued by a wide variety of PKIs and CA products; • an operational PKI bridge pathway between the prototype instance of the Federal Bridge CA and the prototype instance of the Higher Education Bridge CA, funded by and operated by EDUCAUSE • resolution of multiple certificate configuration and directory interoperability problems; • the ability for faculty and staff at academic institutions to download, fill out, sign (multiple options) and send XML forms to a U.S. Federal government Automated Receipt Server and to obtain an automated (signed) email acknowledgement of acceptance; • Implemented multiple forms, multiple signature options e.g. nested and/or peer signatures • the ability of an Automated Receipt Server to acquire and test an XML version of a standard U.S. government form (SF-424, ED1049), and to obtain an email acknowledgement of acceptance, • the ability of the Automated Receipt Server to automatically validate the affixed digital certificates, in the process discovering certificate validation paths to multiple different academic institutions using disparate CA products and services through the Federal Bridge - Higher Ed Bridge pathway and to return a correct status to the server using the return path; • the ability of the Automated Receipt Server to send a digitally signed report containing a copy of the receipt and validation transaction, the certificates validated and a copy of the form to an audit log that satisfies the requirements of the U.S. National Archives and Records Administration for vouching for and archiving records of electronic transactions with the U.S. Federal government. • the ability of the system to parse the data from the validated form and route directly to workflow applications for processing, eliminating re-entry and reducing errors and processing costs 22 PKI Interoperability Pilot - Progress Participating Organizations 23 HEBCA & the PKI Interoperability Pilot • Summary – Successful Prototype and Test Bridge Certificate Authorities for US Higher Education cross-signed with the Prototype FBCA – Production HEBCA just a few short months away to be cross- certified with Production FBCA • NOTE: Policy Mapping and Technical Interoperability already completed – Successful cross-federation processing of digitally signed forms using InfoMosaic technology • NOTE: Pilot is Windows OS based but InfoMosaic also provides support for Linux and Mac support will be available next month – Demonstrated end-to-end paperless office processing of standard government and academic forms – Government archival requirements implemented in accordance with NARA regulations 24 HEBCA & the PKI Interoperability Pilot • Questions? Advertising: http://www.dartmouth.edu/~deploypki/summit05/Summit05.html 25 For More Information • HEBCA Website: http://www.educause.edu/hebca/ • PKI Interoperability Pilot Website: http://pki.od.nih.gov/ Scott Rea - Scott.Rea@dartmouth.edu 26 Design and Implementation of LDAP Component Matching for Flexible and Secure Certificate Access in PKI Sang Seok Lim Jong Hyuk Choi Kurt D. Zeilenga IBM Watson Research Center IBM Watson Research Center IBM Linux Technology Center P.O. Box 218 P.O. Box 218 Carson City, NV Yorktown Heights, NY 10598 Yorktown Heights, NY 10598 zeilenga@us.ibm.com slim@us.ibm.com jongchoi@us.ibm.com Abstract assertion values). However, these simplifications come at a price. Because the string-based encoding in LDAP generally does not Lightweight Directory Access Protocol (LDAP) is the predomi- carry the complete structure of abstract values, adding support for nant Internet directory access protocol and hence so is its use in new syntaxes and matching rules requires ad-hoc developments of the Public Key Infrastructure (PKI). This paper presents the design syntax parsing and matching routines. X.500 protocols, on the other and implementation of LDAP component matching which enhances hand, avoid this problem by use of ASN.1 (Abstract Syntax Nota- flexibility and security of the LDAP directory service when it is tion One) [13] encoding rules, in particular, the Basic Encoding used for the PKI certificate repositories. The component match- Rules [12]. ing together with the prerequisite ASN.1 awareness enables match- ing against arbitrary components of certificates and enables match- Though these limitations were not viewed as a significant problem ing of composite values at the abstraction layer of the underlying during LDAP’s early years, it is clear that a number of directory ASN.1 type definition. This allows searching for certificates with applications, such as PKI, are significantly hampered by these limi- matching components without the need of providing syntax spe- tations. For instance, in PKI, a certificate needs to be located based cific parsing and matching routines (flexibility), without the need upon the contents of its components, such as serial number, issuer of extracting the certificate components and storing them into sepa- name, subject name, and key usage [14]. LDAP search opera- rate attributes which become searchable but mutable (security), and tions do not understand ASN.1 types in the definition of the certifi- without the need of restructuring Directory Information Tree (DIT) cate attribute and assertion [14], because attributes and assertions to support multiple certificates per subject (manageability and per- in LDAP are encoded in octet string with syntax specific encod- formance). In this paper, we describe the architecture, key data ing rules. Not only would it require exceptional effort to support structures, and the proposed methods of enhancing interoperability matching rules such as certificateExactMatch and certificateMatch and performance of our component matching implementation in the as defined in [14], that effort would have to be repeated for each OpenLDAP open source directory software suite. We also propose matching rule introduced to match on a particular component (or the use of component matching in on-line certificate validation and set of components) of a certificate. Because of the large amount of in Web services security. Through performance evaluation of the effort each server vendor must undertake to support each new rule, OpenLDAP component matching, we show that our LDAP compo- few new rules have been introduced to LDAP since its inception. nent matching implementation exhibits the same or higher perfor- Applications had to make due with existing rules. mance compared to the previous approaches. Foreseeing the need to be able to add new syntax and matching rules Keywords without requiring recoding of server implementations, the directory community engineered a number of extensions to LDAP to address PKI, X.509 Certificate, Certificate Repository, Component Match- these limitations. The Generic String Encoding Rules (GSER) [17] ing, LDAP was introduced to be used in describing and implementing new LDAP string encodings. GSER produces human readable UTF- 8 [32] encoded Unicode [28] character string which preserves the 1 Introduction complete structure of the underlying ASN.1 type and supports reuse of the existing LDAP string encodings. Provided that an LDAP The certificate repository in Public Key Infrastructure (PKI) is a server is ASN.1 aware, i.e. it can parse values in ASN.1 encod- means of distributing certificates and Certificate Revocation Lists ing rules into its internal representation of ASN.1 value and can (CRL) to end entities. It stores certificates and CRLs and provides perform matching in that abstraction layer, it is possible to support efficient access methods to them by harnessing storage means with matching of arbitrary types without needing ad-hoc developments communication mechanisms. The directory technology stands out of parsing and matching routines. as the most befitting approach to implementing certificate repos- itories because the X.509 [14] PKI has been standardized in the The component matching [18] mechanism was also introduced to context of the X.500 recommendations as the public key based au- allow LDAP matching rules to be defined in terms of ASN.1. It in- thentication framework on the X.500 directory. troduces rules which allow arbitrary assertions to be made against selected components values of complex data types such as certifi- Lightweight Directory Access Protocol (LDAP) [10] renders cates. For example, the component matching enables matching lightweight directory service by providing direct mapping onto against the selected components of certificates without the need to TCP/IP, simple protocol encoding, reduced number of operations, define a certificate component specific matching rule and without and string-based encoding of names and attribute values (hence of requiring custom code to implement that matching rule for the cer- Certificate Certificate / CRL Registration Authority (CA) Repository (LDAP) Authority (RA) tificate attributes. Though the directory community saw GSER and component match- publish publish ing as an eloquent solution to the LDAP syntax and matching rule certificate certificate limitations, there were some concerns, as most LDAP server im- CRL plementations were not ASN.1 aware, that its adoption would be slow. To fulfill immediate needs of PKI applications, another solu- tion based upon attribute extraction (or “data de-aggregation”) has Certificate / Management CRL Access been being utilized as a practical remedy. The attribute extraction Transactions Management method decomposes a certificate into individual components and Transactions stores them into separate, searchable attributes. Certificate Parsing Server (XPS) [2] automates the attribute extraction process. Al- though this approach has filled the interoperability gap between LDAP and PKI, it is considered to be not a workable solution for PKI applications (and certainly not a workable general solution to End Entities the component matching problem), because it introduced a number of security and management issues. Figure 1. The Architecture of Public Key Infrastructure. In the spring of 2004, IBM undertook an engineering effort to pro- vide ASN.1 awareness (with GSER, BER, DER support) and com- ponent matching functionality for the OpenLDAP Project’s Stand- 2 LDAP in PKI alone LDAP Daemon (slapd), the directory server component of OpenLDAP Software [26]. To our knowledge, this is the first imple- 2.1 LDAP Certificate Repository mentation of the component matching technology in a pure LDAP directory server (second to the View500 [29] directory server from X.509 certificates and CRLs are commonly distributed by the cer- eB2Bcom [8] which is X.500 based). This paper presents a detailed tificate repositories. LDAP directories are the most versatile mech- and comprehensive description of the design and implementation anism of implementing the certificate repositories. Figure 1 illus- of the LDAP component matching for improved PKI support, ex- trates the conceptual interoperation of four entities in PKI. In the tending our previous work [19] which had described component public key registration phase, an end entity sends its identity as well matching in the context of WS-Security [24]. Another contribution as its public key to a Registration Authority (RA). If the identity is of this paper is that it proposes key mechanisms to improve per- validated by the RA, the Certificate Authority (CA) will publish formance and interoperability – attribute / matching rule aliasing, the end entity’s certificate, storing it in the LDAP directory. Af- component indexing, and selective component caching. This paper ter that, the published certificate can be retrieved by any properly will also present a preliminary performance evaluation result which authenticated LDAP client. If the issued certificate is revoked by convinces us that the performance of component matching is on par any reason, the CA is responsible for revoking the certificate by with or better than those of the syntax specific parsing and attribute publishing CRLs to the LDAP directory. LDAP directories serve extraction approaches if the optimization mechanisms proposed in as the central place where the end entities not only can download this paper are used. This in fact provides a strong evidential answer certificates of others in order to send encrypted messages or verify to the debate in the PKI standardization community on whether the digital signatures but also can be informed of the latest certificate component matching technology can be implemented in LDAP di- revocation information by downloading CRLs. rectory servers timely and efficiently. This paper also discusses on the possibility of using the component matching for CRL in order to support on-line certificate status checking using LDAP. It also dis- 2.2 Deficiencies of LDAP Certificate Access cusses on the feasibility of using LDAP component matching for PKI in Web services security. An end entity should be able to send a request to the LDAP cer- tificate repository searching for a certificate having matched values This paper is organized as follows. Section 2 introduces the in- in specific components of the certificate. As a principle example, teroperation of LDAP and PKI and describes the deficiencies of when it wants to retrieve the certificate having a specific serial num- LDAP when it is used for PKI. Section 3 describes the component ber and issued by a specific CA, it will send an assertion against matching technology and its use in PKI enabling secure and flexible serialNumber and issuer components as specified in certificateEx- certificate access. It also discusses on the possibility of certificate actMatch of X.509 [14]. However, the need for matching is not validation against CRL using LDAP component matching. Section limited only to these two certificate components. An end entity may 4 introduces GSER (Generic String Encoding Rules) which facili- want to search for certificates which belong to a subject. It may also tates the ASN.1 awareness in LDAP when it represents the attribute want to restrict the scope of the search for the subject’s certificates and assertion values. In Section 5, we present the design and im- to those having a specific key usage, e.g. nonRepudiation, by using plementation of the ASN.1 awareness and the component matching the keyUsage certificate extension. Because LDAP stores attribute in the OpenLDAP directory server. Section 6 demonstrates the ap- and assertion values in LDAP-specific octet strings which do not plication of the component matching for PKI to the security of Web generally preserve structural information of the underlying ASN.1 services. Section 7 shows experimental results of our prototype types, however, it is far from trivial to provide this component level implementation of the LDAP component matching and proves that matching in a generic and flexible way. the component matching can be accomplished without any loss in performance. Section 8 concludes the paper. X.500 [15] satisfies this demand for component level matching by allowing matching to be defined at the ASN.1 layer. For instance, [14] defines certificateExactMatch and certificateMatch matching DN: o=IBM,c=US DN: o=IBM,c=US (userCertificate:certificateExactMatch:=12345$o=IBM,c=US) (a) Syntax Specific Parsing. (&(x509SerialNumber=12345)(x509KeyUsage=010000000)) (b) Attribute Extraction. DN: x509Serial=12345,cn=John DN: cn=John Doe,o=IBM,c=US Doe,o=IBM,c=US (userCertificate:componentFilterMatch:= and:{ cn: John Doe x509Serial: 12345 item:{ uid: 54321 x509Issuer: o=IBM,c=US component "toBeSigned.subject", certificate: MF4… … rule distinguishedNameMatch, value "cn=John Doe,o=IBM,c=US" } (a) DIT. (b) DIT of Attribute Extraction. item:{ Figure 3. Example Directory Information Tree (DIT). component "toBeSigned.extension.*. extnValue.(2.5.29.15)", rule bitStringMatch, value ‘010000000’B } } 2.3.2 Attribute Extraction ) (c) Component Matching. To address these deficiencies, Klasen and Gietz [22] proposed an alternative solution, based on a practical workaround that PKI ad- Figure 2. Three LDAP Certificate Access Methods. ministrators have been using. A set of attributes are extracted from the certificate and stored as simple, searchable attribute together with the certificate in a newly created entry which is subordinate to the original one. For this purpose, they defined a set of 30 at- rules by specifying them in ASN.1 data type representations. The tributes [22] for the X.509 certificate. Matching is performed on use of ASN.1 specifications is beneficial in the following respects: the extracted attributes. The example DIT with extracted attributes 1) parsing and matching can be automatically accomplished from is illustrated in Figure 3. DIT (a) in Figure 3 consists of person en- the given ASN.1 type specification without providing ad-hoc rou- tries under the base o=IBM,c=US each of which contains a certificate tines; 2) simple but powerful matching rules are derivable from the attribute. After attributes are extracted, the person entry will have a strong expressive power of ASN.1, as exemplified in the use of OP- new subordinate entry whose DN (Distinguished Name) becomes TIOANL in certificateMatch; 3) new matching rules can be easily x509Serial=12345,cn=John Doe,o=IBM,c=US. The attribute extrac- provided by specifying them in ASN.1. tion mechanism not only makes the end entity’s view of a DIT dif- ferent from the CA’s who published the certificates but also doubles The rest of this section explains how the current workarounds try the number of entries at minimum. to provide solution to the above mentioned interoperability gap be- tween LDAP and PKI and introduces the component matching ap- With the attribute extraction mechanism, performing matching proach focusing on its advantages over the earlier workarounds. against components is identical to performing matching against at- tributes as depicted in Figure 2 (b). Although attribute extraction fa- cilitates matching against components of a complex attribute, it can be considered as a suboptimal approach in the following respects. 2.3 LDAP Certificate Access Methods First, matching is performed on the extracted attributes, not on the certificate itself. Because the contents of the extracted attributes are 2.3.1 Syntax Specific Parsing mutable, there is non-zero chance of returning a wrong certificate to a client if the extracted attributes were maliciously forged. It is A brute force approach to providing matching for arbitrary compo- strongly recommended for the client to verify the returned certifi- nents of a certificate against an assertion is to provide certificate- cate again to ensure strong security. In the server side, on the other syntax specific matching rules. For example, it is possible to hand, the server administrator must ensure the integrity of a cer- manually write a special matching routine that matches the cer- tificate and the corresponding extracted attributes in order to mini- tificate attribute against the assertion value consisting only of se- mize this security vulnerability. Second, when there are more than rialNumber and issuer to implement certificateExactMatch which, one certificates in a directory entry, one per key usage for example, in case of X.500 [15], is meant to be derived automatically from it is not possible to pinpoint and return the certificate having the its ASN.1 specification [14]. In OpenLDAP, certificateExactMatch matching component (i.e. key usage for example again) since the is implemented by using certificate decoding libraries provided by searched-for attribute is different from the to-be-returned attribute. OpenSSL [27]. Figure 2 (a) shows an example filter in which the The matched value control [4] does not solve this problem, because predetermined token ’$’ is used to separate the serial number 12345 an LDAP attribute is set of values, not sequence of values. There- and the issuer distinguished name o=IBM,c=US. The server can rec- fore, it is inevitable to transform the DIT structure in designing a ognize the serial number and issuer name by reading two strings certificate DIT to avoid the need for an additional searching step separated by ‘$’. The downside of this approach is obvious. It is in the client [3]. Third, the attribute extraction does not facilitate too costly to define syntax specific matching rules for all possible matching against a composite assertion value as in X.500. It is not components and their combinations. It is also difficult to cope with possible to support a flexible matching as in X.509 certificateMatch the extension mechanisms such as a certificate and CRL extensions. without making LDAP directory servers ASN.1 aware. Certificate.toBeSigned :: = SEQUENCE { 2.3.3 Certificate Parsing Server version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, An automatic attribute extraction mechanism was recently pro- signature AlgorithmIdentifier, posed. The Certificate Parsing Server (XPS) designed by the Uni- issuer Name, versity of Salford [3] extends the OpenLDAP directory server in validity Validity, order to automatically extract and store the certificate components. subject Name, Although it can significantly relieve the PKI administrator’s burden, subjectPublickKeyInfo subjectPublicKeyInfo, it does not improve the attribute extraction mechanism not to suffer issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIOMAL subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL from the three disadvantages of described above. extensions [3] EXPLICIT Extensions OPTIONAL } 2.3.4 Component Matching GSER encodings Component matching is recently published in RFC 3687 [18] in an effort to provide a complete solution to the LDAP - PKI interoper- { version 2, ability problem. All attribute syntaxes of X.500 and LDAP are orig- serialNumber 12345 , inally described by ASN.1 type specifications [15, 10]. However, signature { algorithm 1.2.840.113549.1.14, parameters NULL}, LDAP uses LDAP specific encodings which does not generally pre- serves the structural information in the original ASN.1 type, instead issuer {{type o, value IBM},{type c, value US}}, of relying on an ASN.1 encodings. The component matching de- validity {notBefore {2004 01 13 18 59}, notAfter {2005 01 13 18 59} }, fines a generic way of enabling matching user selected components … of an attribute value by introducing a new notion of component as- sertion, component filter, and matching rules for components. With } component matching, it becomes possible to perform matching of Figure 4. Certificate ASN.1 Specification and GSER Encoding. an assertion value against a specific component of a composite at- tribute value. For example, infrastructure is provided to perform matching against an arbitrary component of an X.509 certificate, assertion value is a component filter. The search filter for compo- such as serialNumber, issuer, subject, and keyUsage. Technical de- nent matching consists of three parts. tails of the component matching will be explained in the following sections. Compared to the attribute extraction approach, component • Component Reference: specifies which component of the at- matching has the following advantages: tribute value will be matched against the assertion value. 1. It does not extract and store certificate components separate • Matching Rule: specifies which matching rule will be used to from the certificates themselves. Therefore, it does not in- perform matching on the values. crease storage requirements and does not open a potential to • Value: An assertion value in GSER. the compromised integrity between a certificate and its ex- tracted attributes. 3.2 Certificate Access 2. Matching is performed not on the extracted attributes’ con- tents but directly on the certificate’s content. It can return only Component matching, as introduced in Section 2.3.4, enables the matched certificate out of multiple certificates in a user’s matching of an assertion value against a specific component of a entry if it is used in conjunction with the matched values con- certificate such as serialNumber, issuer, subject, and keyUsage. If trol [4]. a client receives a reference to a certificate consisting of the name 3. It becomes convenient to provide a complex matching flexi- of the issuing CA and its serial number, the client has to search bly because matching between attribute and assertion values for the certificate having matching issuer and serialNumber com- is performed at the ASN.1 layer. ponents in a certificate repository. Alternatively, a client may want to retrieve communicating party’s certificates, not all of them, but only the ones for the non-repudiation purpose, by matching its dis- 3 Component Matching for PKI tinguished name and key usage against the subject and keyUsage components of the certificate. For instance, the client can make 3.1 Component Matching and Its Usage an LDAP search request having the search filter illustrated in Fig- ure 2 (c) to search for the certificates of cn=John Doe,o=IBM,c=US The attribute syntaxes of X.500 are defined in ASN.1 types. The that are arranged to be used for non-repudiation. The example com- type is structurally constructed from basic types to composite types ponent filter of Figure 2 (c) contains two component assertions, one just like C struct definition. Every field of an ASN.1 type is a com- for subject and the other for keyUsage. The component references ponent. Based on ASN.1 types, component matching [18] defines to these components begin with toBeSigned which is a sequence how to refer to a component within an attribute value and how to of certificate components to be digitally signed for immutability. match the referred component against an assertion value. Match- toBeSigned.serialNumber refers to the serialNumber component ing rules are defined for the ASN.1 basic and composite types. It of a certificate while toBeSigned.extension.*.extnValue.(2.5.29.15) also defines a new assertion and filter tailored for a component, or refers to any extension of keyUsage type. In the latter example, each field of the ASN.1 type. These definitions are based on ASN.1 (2.5.29.15) is the object identifier (OID) of the keyUsage extension. so that they can be applied to any complex syntax, as long as it is It is contained in OCTET STRING of the extnValue of any com- specified in ASN.1. ponents of extensions certificate component. In other words, the reference means identifying all keyUsage extension components. The search filter for component matching is a matching rule asser- tion [10] whose matching rule is componentFilterMatch and whose The component matching rule specifies which matching rules will X.509 Certificate OpenLDAP Server (slapd) ASN.1 Specification Component Filter Processing Certificate Attribute Processing Component Matching Matching Component (Assertion) Rule Rule (Attribute) eSNACC Compiler 6 5 Component Component GSER GSER Decoder Decoder Extractor BER DER GSER Extractor Component Component Component Component Tree Extractor Decoder Encoder Certificate Module Assertion Value Reference Caching Caching Loading 3 Matching Rules Indexer Component Component Filter Filter 4 DER DER Decoder Decoder Internal ASN.1 Data Representation Parser Parser (GSER) (GSER) 2 LDAP Component Component Certificate Filter Search Request 1 Figure 5. Architecture of Component Matching in OpenLDAP. be used to perform matching a certificate’s component against fully revised to reduce the CRL download traffic which can degrade an assertion value. Either existing matching rules or newly de- the scalability of PKI significantly, it still requires the end entities fined matching rules can be used as the component matching rules. to store CRLs in its local storage in order to facilitate efficient and Matching rules for composite types can be provided by combining off-line operation. On the other hand, on-line certificate validation those of their subordinate types. allComponentsMatch implements protocols are also proposed in order to cope with the on-line end matching at the ASN.1 layer whereas derived matching rules can be entities which need more fresh information on certificate validity. defined to override it with specific syntaxes. Because the on-line end entities need not store the certificate status information in its storage, the on-line protocols also eliminate the RFC 3687 [18] defines which matching rules can be applied to requirement for the hefty local certificate storage. Online Certifi- each of the ASN.1 types. In the example component filter in Fig- cate Status Protocol (OCSP) [21] and Simple Certificate Validation ure 2 (c), distinguishedNameMatch is used for subject and bit- Protocol (SCVP) [9] are two examples of the on-line certificate val- StringMatch is used for keyUsage. The component assertion value idation protocols. is a GSER-encoded value asserted against the component selected by the component reference. In Figure 2 (c), the value cn=John We conceive that component matching enabled LDAP can also be Doe,o=IBM,c=US is the GSER encoded ASN.1 UTF8 STRING and used as an on-line certificate validation protocol. CRL is a se- the value ‘010000000’B is the GSER encoded ASN.1 BIT STRING quence of pairs of a revoked certificate’s serial number and revoked value. time [11]. In order to check status of the certificate, the client needs to make a component assertion against the serial number of the cer- The client sends a search request containing the component filter to tificate under scrutiny. Then, the LDAP server will perform compo- a component matching enabled LDAP directory server. In response, nent matching on the CRL against the assertion to find the asserted the client will be returned with those entries having the matching serial number in the CRL. This is possible with component match- certificate if there is any. After checking the authenticity and in- ing, since the LDAP server understands the structure of the CRL tegrity of the returned certificate, the client can extract the public and is able to compare specific components of the CRL against the key out of the certificate for further use. component assertion. In the attribute extraction approach, however, the serial numbers of all the elements of the revoked certificate list must be extracted as separate attributes which need to be stored 3.3 Certificate Revocation List (CRL) Access in the individual subordinate entries. This not only increases the amount of storage and increases the complexity of managing direc- Although certificates were valid at the time when they were issued, tory significantly, but also makes the server vulnerable to malicious CA must revoke certificates occasionally because the key pair for a attacks as explained in Section 2.3.4. certificate can be compromised or the binding between an identity and a certificate become invalid. As a result, a certificate should With component matching, the whole CRL does not necessarily be validated when it is used. Otherwise, the client might incur not have to be downloaded to the client and scanned by the client so only incomplete, but also insecure transactions. The CRL mecha- as to save the network bandwidth and the client’s computing power nism [11] provides a means of performing validation of certificates significantly. Especially for the clients which have limited com- against periodically published list of revoked certificates, or Cer- puting power and low bandwidth such as mobile devices, compo- tificate Revocation List (CRL). A CRL is periodically generated by nent matching will be very efficient solution for the client to access the CA and is made available through certificate repositories such PKI. Furthermore, an LDAP server already has been widely used as LDAP directories. Although the CRL mechanism has been care- typedef struct Certificate { typedef typedef struct structslap_component_desc {{ typedef typedef structslap_component_desc slap_component_desc { ComponentDesc* comp_desc; typedefstruct function_ptr slap_component_desc slap_component_desc{{ encoder_function; struct function_ptr encoder_function; ComponentVersion* version; function_ptr function_ptr encoder_function; encoder_function; function_ptr function_ptr decoder_function; function_ptr encoder_function; decoder_function; ComponentCertificateSerialNumber serialNumber; function_ptr function_ptr decoder_function; decoder_function; function_ptr function_ptr extractor_function; function_ptr decoder_function; extractor_function; ComponentAlgorithmIdentifier* signature; function_ptr function_ptr extractor_function; extractor_function; function_ptr function_ptr matching_functino; function_ptr extractor_function; matching_functino; ComponentName* issuer; function_ptr function_ptr matching_functino; matching_functino; }}ComponentDesc; function_ptr matching_functino; ComponentValidity* validity; }ComponentDesc; }ComponentDesc; ComponentDesc; } ComponentDesc; ComponentName* subject; ComponentSubjectPublicKeyInfo* subjectPublicKeyInfo; ComponentUniqueIdentifier issuerUniqueIdentifier; ComponentUniqueIdentifier subjectUniqueIdentifier; ComponentExtensions* extensions; } ComponentCertificate; typedef ComponentInt typedef struct AlgorithmIdentifier { typedef struct Name { typedef struct SubjectPublicKeyInfo { ComponentCertificateSerialNumber; ComponentDesc* comp_desc; ComponentDesc* comp_desc; ComponentDesc* comp_desc; ComponentOid algorithm; enum NameChoiceId { ComponentAlgorithmIdentifier* algorithm; typedef struct Int { ComponentAnyDefinedBy parameters; NAME_RDNSEQUENCE ComponentBits subjectPublicKey; ComponentDesc* comp_desc; } ComponentAlgorithmIdentifier; } choiceId; } ComponentSubjectPublicKeyInfo; int value; union NameChoiceUnion { } ComponentInt; typedef ComponentAny ComponentRDNSequence* rdnSequence; typedef struct Bits { ComponentAnyDefinedBy; } a; ComponentDesc* comp_desc; } ComponentName; AsnBits value; typedef struct Oid { } ComponentBits; ComponentDesc* comp_desc; typedef ComponentList AsnOid value; ComponentRDNSequence; } ComponentOid; typedef struct List { ComponentDesc* comp_desc; AsnList comp_list; } ComponentOid; Figure 6. Certificate Component Tree. for distributing CRLs and certificates. Hence, if the server can per- Hence, GSER is an essential mechanism to ASN.1 awareness and form on-line validity checking over the CRL as well, it will be very component matching. practical and efficient alternative to OCSP which needs additional software, or an OCSP responder. Figure 4 shows the ASN.1 type specification of a toBeSigned and its GSER encodings. The certificate is SEQUENCE so that there In [6], we also propose to structure the internal representation of are curly braces at the beginning and at the end of its GSER encod- CRL as an authenticated data structure such as the Certificate Revo- ings. It has version, serialNumber, etc. as its components inside of cation Tree (CRT) [16] and the authenticated 2-3 tree [23]. Together SEQUENCE. Within the braces, there is version and 2, or its value, with the component matching, it makes certificate validation result followed by comma which separates the subsequent field encoding. from an LDAP server unforgeable while not requiring to have the GSER defines each basic type’s encoding and then combines them LDAP server as a trusted entity nor to sign every LDAP response structurally to a more complex one by using “{”, “,” and “}”. On on the fly as in OCSP. the other hand, a native LDAP encoding does not have any system- atic rule to construct the structure information of attribute value in it. 4 GSER (Generic String Encoding Rules) A native LDAP encoding does not represent structure of an ASN.1 type. Instead, it is either in octet string or in binary. With the LDAP 5 Component Matching Implementation in encoding, as a result, it is difficult to contain the structural informa- OpenLDAP tion of ASN.1 type in its representation. In order to solve this prob- lem, S. Legg [17] recently proposed GSER (Generic String Encod- The overall conceptual architecture of the component matching in ing Rules). Component matching uses GSER as its basic encoding the OpenLDAP slapd directory server is illustrated in Figure 5. for the component assertion value. GSER generates a human read- Given the ASN.1 specification of the X.509 certificate as an in- able UTF-8 character string encoding of a given ASN.1 specifica- put, the extended eSNACC ASN.1 compiler generates the slapd in- tion with predetermined set of characters to keep the structure such ternal data representation of the X.509 certificate and their encod- as ‘{’, ‘}’, and ‘,’. It defines UTF8 string encodings at the lowest ing / decoding routines. We extended the eSNACC ASN.1 com- level of the ASN.1 built-in types such as INTEGER, BOOLEAN, piler [7] to support GSER in addition to the originally supported and STRING types and then it builds up more complex ASN.1 types BER and DER [7]. It also generates component equality matching such as SEQUENCE and SET from the lowest level by using the rules, component extract functions, and component indexer func- characters. Thus, the structural information of an ASN.1 specifica- tions which will be discussed later in this section in detail. In or- tion is maintained in encodings so that it can be recovered in the der to facilitate the integration of the newly defined syntaxes with- decoding process easily. By using GSER to store attribute values out the need of rebuilding the slapd executable, the generated data instead of the native LDAP encoding, an LDAP server is capable structures and routines are built into a module which can be dynam- of identifying the structure of ASN.1 specification of the attribute. ically loaded into slapd. The overall flows of LDAP component Furthermore, the component filter itself is also encoded in GSER. search is explained as follows; 1. On the client side, a search for components of X.509 certifi- New Matching Rule cate is initiated by the inclusion of the ComponentFilter in the Component Reference filter of the search request. A ComponentFilter consists of (userCertificate:componentFilterMatch ComponentAssertions each of which is in turn comprised of := not:item:{ component, rule, and value. component “toBeSigned.serialNumber”, rule integerMatch, 2. On the server side, whenever slapd detects that the search re- Component Filter value 12345 quest contains ComponentFilter, it parses the incoming com- } ponent filter to obtain assertion values and component refer- ) Component Assertion ences. The assertion values are also converted to the ASN.1 internal representation by the GSER decoder. Figure 7. Example Component Filter. 3. Retrieve the entry cache to see if the target certificate’s de- coded component tree is cached. If so, skip the following steps upto the step 6. 5.1.2 Internal Representation of ASN.1 Type 4. If it is not cached, by using an appropriate ASN.1 decoder, slapd decodes the certificate attribute into the component tree, A new data structure of slapd is needed to represent an attribute the ASN.1 internal representation, when loading the candi- value as its components because the original data structure for date entries containing certificate for matching. Because a attribute types does not contain the structural information of an certificate is DER encoded, DER decoder is used to construct ASN.1 type in its representation. Every field of an ASN.1 type a certificate’s component tree. is a component which is addressable by a component reference. In our implementation, the component data structure consists of two 5. The component reference is fed into the component extractor parts: one to store the value of the component; the other to store to obtain the component subtree which is referenced by com- a component descriptor which contains information on how to en- ponent reference out of the attribute component tree. code, decode, and match the values. 6. The assertion component and the extracted attribute compo- nent are then matched together by the matching rule corre- The data structure of a component appears as a tree which keeps sponding to the component which is generated also by the the structural information of the original ASN.1 specification using extended eSNACC compiler. Matching is performed at the nodes and arcs. Each component node of the tree not only has data abstract level using the internal ASN.1 data representation. values but also represents the structural information of the given ASN.1 specification by having links to subordinate nodes. In the The rest of the section provide detailed description of the compo- tree, any node can be referenced by a component reference in order nent matching in two steps. After first describing how to make to perform matching on the corresponding component. Hence, we the OpenLDAP directory server ASN.1 aware in detail, compo- need a function to traverse the tree and locate the referenced node. nent filter processing, aliasing, component indexing, and compo- The ASN.1 compiler also generates component extractor routines nent caching will be described. for this purpose. Figure 6 illustrates the component data structure for Certifi- cate.toBeSigned. For the convenience of illustration, only seri- alNumber, signature, issuer, and subjectPublicKeyInfo are shown with their component subtrees among ten components of Certifi- 5.1 ASN.1 Awareness cate.toBeSigned. Let’s look at subjectPublicKeyInfo in more de- tail. Its component data structure, ComponentSubjectPublicKey- 5.1.1 eSNACC Compiler Info, contains a pointer to its component descriptor and its own sub- ordinate components, algorithm and subjectPublicKey. Algorithm Figure 6 shows the internal data representation of the toBeSigned is represented by ComponentAlgorithmIdentifier and subjectPub- ASN.1 type along with the representations of some of its key com- licKey is of the ASN.1 BIT STRING type which is represented by ponents. The data structures for this ASN.1 data representation ComponentBits. Leaf nodes of the component tree, such as Compo- are automatically generated by the eSNACC compiler from the nentBits and ComponentInt, contain the values of the ASN.1 basic given ASN.1 specification of toBeSigned. The generated data struc- types. ture for the toBeSigned has data fields corresponding to compo- nents of the toBeSigned ASN.1 type. Once the internal data struc- ture for toBeSigned is instantiated, it can be converted to DER 5.1.3 Syntax and Matching Rules by DEnctoBeSigned() and back to the internal representation by DDectoBeSigned(). An attribute is described by an attribute type in LDAP. An attribute type contains two key fields which help to define the attribute as Component matching can be performed for any composite at- well as the rules that attribute must follow. The first field is syn- tributes which are encoded as one of the ASN.1 encoding rules. tax which defines the data format used by the attribute type. The In addition to the DER used for a certificate, we have implemented second field is matching rule which is used by an LDAP server a GSER backend in the extended eSNACC compiler. GSER can to compare an attribute value with an assertion value supplied by be used as an LDAP-specific encodings for newly defined attribute LDAP client search or compare operations. Attributes must include types. With GSER, string-based LDAP-specific encodings can the matching rules in their definition. At least, equality matching maintain the structure of their corresponding ASN.1 types. The as- rule should be supported for each attribute type. From the view- sertion values in the component filter are also represented in GSER point of an LDAP server, an ASN.1 specification defining a new and the extended eSNACC compiler is used to decode them into attribute type requires a new syntax and its matching rule to be their internal representations. defined. To fully automate the component matching in which the Table 1. Attribute Aliasing Table. Alias Attribute Aliased Attribute Component Reference Matching Rule x509certificateSerialNumber userCertificate toBeSigned.serialNumber integerMatch x509certificateIssuer userCertificate toBeSigned.issuer distinguishedNameMatch composite attribute types are defined in ASN.1, we extended the Table 2. X509 Certificate Decoding Time. eSNACC compiler to generate the basic equality matching rule of a d2i X509() ASN.1 given ASN.1 type, or allComponentMatch matching rule specified OpenSSL Decoder in RFC 3687 [18]. allComponentMatch matching rule evaluates to Time (usec) 32.74 40.20 true only when the corresponding components of the assertion and the attribute values are the same. It can be implemented by per- forming matching from the topmost component which is identified Attribute alias registers a set of virtual attributes to an LDAP by the component reference recursively down to the subordinate server. The virtual attributes themselves find correspond- components. The generated matching function of each component ing matching rules and component references by looking up can be overridden by other matching functions through a matching an attribute alias table. The example attribute alias ta- rule refinement table. Therefore, it is possible that a syntax devel- ble is shown in Table 1. X509certificateSerialNumber at- oper can replace the compiler-generated matching functions with tribute is aliased to “userCertificate.toBeSigned.serialNumber” the existing matching functions of slapd which might be more de- with the integerMatch matching rule. Hence, the filter sirable. In order to support this refining mechanism, slapd checks “(x509certificateSerialNumber=12345)” is considered equivalent the refinement table whether it is overridden by looking up the ta- to “(userCertificate:ComponentFilter:=item:component userCer- ble, whenever a matching functions are executed. tificate.toBeSigned.serialNumber, rule caseExactMatch, value 12345)”. With the attribute aliasing, clients only have to form sim- ple assertions to utilize component matching. Matching rule alias 5.2 Component Matching works in a similar way. An alias matching rule is mapped into the corresponding component reference and matching rule. 5.2.1 Component Assertion and Filter RFC 3687 [17] defines a new component filter as the means of ref- 5.2.3 Component Indexing erencing a component of a composite attribute and as the means The maintenance of proper indices is critical to the search perfor- of representing an assertion value for a composite attribute types. mance in the Component Matching as much as in the conventional Component assertion is an assertion about presence or values of attribute matching. In slapd, the attribute indexing is performed by components within an ASN.1 value. It has a component refer- generating a hash key value of the attribute syntax, matching rule, ence to identify one component within an attribute value. Compo- and the attribute value and maintain the list of IDs of those entries nent filter is an expression of component assertion, which evaluates having the matching value in the set of attribute values of the in- to either TRUE, FALSE, or Undefined while performing match- dexed attribute. ing. Figure 7 illustrate the example component filter. The compo- nent reference or toBeSigned.serialNumber identifies one compo- The component indexing can be specified in the same way as the nent in the certificate attribute value. In the component reference, attribute indexing, except that the component reference is used to “.” means identifying one of components subordinate to the pre- specify which component of a composite attribute to be indexed. If ceding component. In the component assertion, rule is followed the referenced component is a basic ASN.1 type, the indexing pro- by an integerMatch matching rule [15] which will be used to com- cedure will be the same as the attribute indexing. The indices for pare the following assertion value with the referenced component the referenced component are accessed through a hashed value of of the attribute value. The routines required to support the com- the corresponding syntax, matching rule, and value in the index file ponent filter and the component assertion were hand-coded while for the referenced component of the composite attribute. In OpenL- the routines for the component assertion values are automatically DAP, the indexing of the composite component is centered on the generated from a given ASN.1 type. GSER encoding of the component value. The hash key of a com- ponent value is generated from its GSER encodings together with 5.2.2 Attribute / Matching Rule Aliasing its syntax and matching rule. For the SET and SET OF constructed types, it is required to canonicalize the order of the elements in To enable component matching, clients as well as servers need to the GSER encodings before generating the hashed key value. For support GSER and new component matching rules. However, the component reference of SET OF and SEQUENCE OF con- client side changes will be minimal if at all, because the component structed types, its is needed to union the indices for each value ele- filter can be specified by using the existing extensible matching rule ment of SET OF and SEQUENCE OF. mechanism of LDAPv3 and the component assertion value is rep- resented as the text centric GSER encoding rules. Especially, the 5.2.4 Component Caching clients that accept search filters as strings require no changes to uti- lize component matching other than filling in the necessary compo- Whenever a certificate is matched against an incoming component nent filter as the search filter. However, for those clients who have filter, it is repeatedly decoded into the internal representation from search filters hard coded in them, we propose an attribute aliasing DER. This requires non-negligible CPU cycles as presented in Ta- mechanism which maps a virtual attribute type to an attribute com- ble 2. ponent and a component matching rule and a matching rule aliasing mechanism which maps a virtual matching rule to a component as- In order to eliminate the repeated decoding overhead, we decided sertion. to cache certificates in their decoded form, i.e. in the component 8fb2adb53a9056a511d356947cedeec0 o=IBM,c=US 0 (a) XER. { serialNumber "8fb2adb53a9056a511d356947cedeec0", issuer "o=IBM,c=US" , keyUsage ‘010000000’B } (b) GSER. Figure 8. Example GenericCertificateReference. tree structure explained in Section 5.1.2. In the OpenLDAP direc- directly accesses PKI; the other indirectly accesses it by using ser- tory server, the entry cache is provided to store frequently requested vice proxies such as XML Key Management System (XKMS) [30] entries to enable very low latency access [5]. We extended the cur- which provides clients with a simple-to-use interface to a PKI so as rent entry cache to store decoded certificates along with other at- to hide the complexities of the underlying infrastructure. tributes of the entry. We devised various caching policies for the entry cache. In early implementations, we decided to cache a de- In the X.509 token profile of WS-Security [25], it is defined that the coded certificate as a whole, along with its entry in the entry cache. following three types of token references can be used: The size of a certificate is 899Bytes and that of the corresponding component tree is 3KBytes. Caching all the decoded component 1. Reference to a Subject Key Identifier: value of certificate’s tree consumes more than three times as much memory compared to X.509SubjectKeyIdentifier. the base entry caching. To reduce the memory requirements, we de- 2. Reference to a Security Token: either an internal or an exter- vised an indexing based caching policy. Since it is a common prac- nal URI reference. tice to index those attributes that are likely to be asserted, caching only those indexed components is a very practical solution to re- 3. Reference to an Issuer and Serial Number: the certificate is- duce the memory requirement. In our experiment, the serial number suer and serial number. component was cached which takes only 148Bytes of memory. Because it is defined as extensible, any security token can also be used based on schemas. It is shown in Figure 8 that the 6 Component Matching in WS-Security element of is used as the security token. defined in [31] contains various references SOAP (Simple Object Access Protocol) is a protocol for invoking such as X509IssuerSerial, X509SubjectName, X509SKI, and so on. methods on servers, services, components, and objects [1]. It is a With the ASN.1 awareness and the component matching support in way to create widely distributed, complex computing environments the OpenLDAP directory server, these references can be used with- that run over the Internet using existing Internet infrastructure, en- out the need of implementing syntax specific matching rules for abling Web service developers to build Web services by linking het- various types of references. It is also possible in erogeneous components over the Internet. For interpretability over to use elements from external namespace for further flexibility. heterogeneous platforms, it is built on top of XML and HTTP which are universally supported in most services. WS-Security is recently Figure 8 shows one such example. Here, GenericCertificateRefer- published as the standard for secure Web Services [24]. It provides ence element from dsext namespace is used to provide a generic a set of mechanisms to help Web Services exchange secure SOAP reference mechanism which implements CertificateMatch in the message. WS-Security provides a general purpose mechanism for X.509 recommendation [14]. The reference consists of a sequence signing and encrypting parts of a SOAP messages for authenticity of certificate attributes, serialNumber, issuer, subjectKeyIdentifier, and confidentiality. It also provides a mechanism to associate se- authorityKeyIdentifier, certificateValid, privateKeyValid, subject- curity tokens with the SOAP messages to be secured. The security PublicKeyAlgID, keyUsage, subjectAltName, policy, pathToName token can be cryptographically endorsed by a security authority. each of which is defined optional. By using the example reference, It can be either embedded in the SOAP message or acquired ex- it would be possible to perform security key reference in a very ternally. There are two types of PKI clients in WS-Security: one flexible way. It would be possible to search for a certificate having 20K 4K 18K CM CM OpenSSL 16K OpenSSL XPS 3K XPS 14K 12K op/sec op/sec 10K 2K 8K 6K 1K 4K 2K 0K 0K 1 4 8 15 20 1 4 8 15 20 # of Clients # of Clients (a) 100K Entries (No Memory Pressure). (b) 500K Entries (High Memory Pressure). Figure 9. The Performance of Three Approaches. a subjectAltName with a specific keyUsage. Figure 8(a) shows that In the experiment, OpenLDAP stand-alone directory server, slapd, the reference is encoded in XML while Figure 8 (b) shows that the was used as an LDAP certificate repository testbed for all three reference is encoded in GSER. methods. Slapd as of OpenLDAP version 2.2.22 supports both the component matching and the certificate specific matching. The at- With the component matching enabled LDAP server, the GSER en- tribute extraction mechanism was tested by using the XPS patch to coded reference value can be used as an LDAP assertion value in OpenLDAP which was contributed to the OpenLDAP project by a component filter. With the ASN.1 awareness support, the LDAP University of Salford. XPS was used to automatically generate the server is now capable of understanding the structure of the Certifi- DIT for the attribute extraction. The same version of slapd was cateAssertion type when configured with its ASN.1 definition. Be- tested for all three mechanisms for the LDAP certificate repository. cause encoders / decoders for various encoding rules (GSER, DER, XER ...) are automatically generated and integrated into the LDAP Fgure 9 (a) shows the throughput of three approaches, varying the server, it is possible to use ASN.1 values encoded in those encoding number of clients. With 100k entries, the peak throughput of com- rules as an assertion value in an LDAP search operation. ponent matching and attribute extraction mechanisms are almost the same. The certificate-syntax specific matching (OpenSSL decoder) With the ASN.1 aware and component matching enabled LDAP exhibits slightly lower performance than the other two methods. We server, flexible reference formats for X.509 certificates can now be attribute the reason of lower throughput to longer code path of slapd defined in ASN.1 to configure the LDAP server to understand the such as normalization and sanity checks of assertion values when it reference. The required matching rules, encoders, and decoders for uses the OpenSSL library. In order to observe the behavior of the the reference type will be automatically generated and integrated to three methods in the presence of memory pressure, we increased the the LDAP server. This increased flexibility will foster the flexible number of entries to 500K and the database cache size is reduced use of security token references in the LDAP server by making it from 1GB to 200MB. With this configuration, only small portion easy to create and update references. of the entries can be cached and hence the system suffers from fre- quent memory swapping. Figure 9 (b) shows that the throughput of all three methods are degraded significantly compared to Figure 9 7 Experimental Results (a). The peak throughput of component matching is 3250 ops/sec, significantly degraded from 17,057 ops/sec with no memory con- We used MindCraft’s DirectoryMark [20] tools to generate the di- straint. The attribute extraction mechanism is hit by even further rectory entries and client scripts containing a list of LDAP opera- performance degradation than the other two mechanisms. This is tions. The client scripts were run on an 8-way IBM xSeries 445 because the number of entries becomes doubled by extracting at- server with Intel Xeon 2.8GHz processors and the directory server tributes and by having them as separate entries subordinate to the was run on an IBM xSeries 445 server with 4 Intel Xeon 2.8Ghz original ones. This results confirms that the component matching is processors and with 12GB of main memory running SUSE SLES9 a superior approach to the attribute extraction with respect to per- (Linux kernel version 2.6.5). We used the transactional backend formance as well as to security and manageability. (back-bdb) of OpenLDAP version 2.2.22 together with Berkeley DB 4.3 and OpenSSL 0.9.7 for the evaluation. Two different size DITs with 100K and 500K entries were used for evaluation. Our in- 8 Conclusion tension of using two different size DITs was to observe the through- put of slapd with and without memory pressure. With 100k entries, Although it is a general consensus in the PKI standardization work- all the entries was able to be cached into the DB cache. On the other ing group that the component matching is a complete solution to hand, with 500k entries, we observed that the server experienced a the LDAP - PKI interoperability problem, it was under debate that number of memory swapping and disk I/O due to memory shortage. its adoption in LDAP servers might be slow and an alternative so- The directory was indexed for cn, sn, email of inetOrgPerson and lution needed be pursued in the interim. In this paper, we have pre- for serialNumber and issuer of userCertificate (or the corresponding sented the design and implementation of the component matching extracted attributes in the case of attribute extraction mechanism). in OpenLDAP slapd. Our work provided a strong evidence that the component matching can be implemented in pure LDAP-based di- [13] ITU-T Rec. X.680, Abstract syntax notation one (ASN.1): rectory servers without exploding complexity and degrading perfor- Specification of basic notation, December 1997. mance. Our work also proposed a number of enhancements to the [14] ITU-T Rec. X.509, The directory: Public-key and attribute component matching technology to improve performance and inter- certificate frameworks, March 2000. operability with legacy clients. In this paper, we also proposed the use of the component matching enabled LDAP as a secure on-line [15] ITU-T Rec. X.500, The directory: Overview of concepts, certificate validation protocol. We further demonstrated the useful- models and service, February 2001. ness of the component matching in WS-Security as a key applica- [16] P. C. Kocher. On certificate revocation and validation. In tion. As PKIs are being adopted in larger scale and in more critical Proc. of the 2nd Int’l Conference on Financial Cryptography deployments, it becomes more important to provide as complete (Lecture Notes in Computer Science, Vol. 1465), pages 172– a solution as possible, especially when it comes to security. The 177, 1998. component matching technology enables more secure and flexible implementation of LDAP certificate repositories for PKI without [17] S. Legg. Generic string encoding rules. RFC 3641, October compromising performance. 2003. [18] S. Legg. X.500 and LDAP component matching rules. RFC 9 Availability 3687, February 2004. [19] S. S. Lim, J. H. Choi, and K. D. Zeilenga. Secure and flexible The component matching software is included in OpenLDAP certificate access in WS-Security through LDAP component release as a module and can be downloaded at http://www. matching. In ACM Workshop on Secure Web Services held in openldap.org/software/download/. The eSNACC ASN.1 conjunction with the 11th ACM Conference on Computer and compiler can be obtained from DigitalNet at http://digitalnet. Communications Security, October 2004. com/knowledge/download.htm. [20] Mindcraft. DirectoryMark. http://www.mindcraft.com/ directorymark/. 10 References [21] M. Myers, R. Ankney, A. Malpani, and C. Adams. Internet X.509 public key infrastructure online certificate status proto- [1] D. Box and D. Ehne. Simple object access protocol (SOAP). col - OCSP. RFC 2560, June 1999. W3C Note, May 2000. [22] N. Klasen and P. Gietz. Internet X.509 public key infrastruc- [2] D. W. Chadwick. Deficiencies in LDAP when used to support ture lightweight directory access protocol schema for X.509 PKI. Comm. of the ACM, 46(3), March 2003. certificates, , October 2004. LDAP to support X.509-based PKIs. In 17th Annual IFIP [23] M. Naor and K. Nissim. Certificate revocation and certifi- WG 11.3 Working Conference on Database and Applications cate update. In Proc. of the 7th USENIX Security Symposium, Security, August 2003. pages 217–228, January 1998. [4] D. W. Chadwick and S. Mullan. Returning matched values [24] OASIS. Web services security: SOAP message security 1.0 with LDAPv3. RFC 3876, September 2004. (WS-Security 2004). OASIS Standard 200401, March 2004. [5] J. H. Choi, H. Franke, and K. D. Zeilenga. Performance of the [25] OASIS. Web services security: X.509 certificate token profile. OpenLDAP directory server with multiple caching. In Pro- OASIS Standard 200401, January 2004. ceedings of International Symposium on Performance Eval- uation of Computers and Telecommunication Systems, July [26] OpenLDAP. http://www.openldap.org. 2003. [27] OpenSSL. http://www.openssl.org. [6] J. H. Choi, S. S. Lim, and K. D. Zeilenga. On-line certificate [28] The Unicode Consortium. The Unicode Standard, Version 4.0. revocation via LDAP component matching. To be presented Addison-Wesley, Boston, 2003. in DIMACS Workshop on Security of Web Services and E- Commerce, May 2005. [29] View500. http://www.view500.com. [7] DigitalNet. Enhanced SNACC ASN.1 software. http:// [30] W3C. XML key management specification (XKMS). W3C www.digitalnet.com/knowledge/snacc_home.htm. Standard, March 2001. [8] eB2Bcom. http://www.e2b2com.com. [31] W3C. XML - signature syntax and processing. W3C Stan- dard, February 2002. [9] T. Freeman, R. Housley, A. Malpani, D. Cooper, and T. Polk. Simple certificate validation protocol (SCVP). [32] F. Yergeau. UTF-8, a transformation format of ISO 10646. , Feburuary 2005. RFC 3629, November 2003. [10] J. Hodges, R. Morgan, and M. Wahl. Lightweight directory access protocol (v3): Technical specification. RFC 3377, September 2002. [11] R. Housley, W. Ford, W. Polk, and D. Solo. Internet X.509 public key infrastructure certificate and CRL profile. RFC 2459, January 1999. [12] ITU-T Rec. X.690, ASN.1 encoding rules: Specification of basic encoding rules (BER), canonical encoding rules (CER), and distinguished encoding rules (DER), 1994. IBM Research / IBM Linux Technology Center Design and Implementation of LDAP Component Matching for Flexible and Secure Certificate Access in PKI Sang Seok Lim Jong Hyuk Choi Kurt Zeilenga IBM Research IBM Research IBM Linux Technology Center slim@us.ibm.com jongchoi@us.ibm.com zeilenga@us.ibm.com 4th PKI R&D Workshop, Gaithersburg MD 2005 © 2005 IBM Corporation Outline  Introduction  LDAP-PKI Interoperability Limitation  Interoperability Enabling Technologies – Component Matching – ASN.1 Awareness – Generic String Encoding Rule (GSER)  OpenLDAP Implementation – ASN.1 Generation of ASN.1 Decoders / Matching Rules – Component Matching Architecture and Data Structures – Component Matching Optimizations  Performance Evaluation  Summary 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 OpenLDAP Component Matching: Overview 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Usage of LDAP in PKI  Certificate access protocols in PKI – LDAP, HTTP, FTP, etc.  LDAP: a predominant way of implementing a PKI repository – X.509 was originally specified in the X.500 context – LDAP is predominantly used directory protocol for the Internet • Various protocol operations: search, modify, update, etc • Authentication: Simple Authentication Security Layer (SASL) • LDAP Control • Access control  LDAP has X.500 DAP simplified by mainly – String-based encoding • Incapable of preserving structural information • DAP uses ASN.1 encodings (BER/DER) – Direct TCP/IP mapping – Simple-protocol encoding 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Certificate Access using LDAP 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Certificate Structure and Encodings (bits-on-the-line) The structural information of ASN.1 types specification is preserved in the encodings DER: Distinguished Encoding Rules 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 LDAP Client Side Requirement Requirement: Component-level expressive power of LDAP search filters Deficiency: LDAP’s incapability of composing a component-level filter!! New Newdefinitions definitionsofofcomponent componentassertion assertionand andfilter filterby by Component ComponentMatching Matching(RFC3687) (RFC3687) 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 LDAP Server Side Requirement Requirement: Restore structural information of ASN.1 specifications for component-level matching Deficiency: LDAP string encoding which do not preserve structural information ASN.1 ASN.1awareness awarenessininLDAP LDAPdirectory directoryserver server by byusing using an anASN.1 ASN.1compiler compiler 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Certificate Syntax Specific Parsing  Parsing the blobs (DER) by certificate-syntax specific decoders OpenSSL DER Decoder  Limited and inflexible component-level filter composing – Example search filter userCertificate:certificateExactMatch=cn=CA,o=IBM,c=US$$12345 userCertificate:certificateExactMatch=cn=CA,o=IBM,c=US 12345  Disadvantages – Inflexibility issuer serial separator 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Attribute Extraction  Example search filter (use an attribute-level filter) (&((x509KeyUsage=010000000)(x509Subject=cn=John,o=IBM,c=US))) (&((x509KeyUsage=010000000)(x509Subject=cn=John,o=IBM,c=US)))  Certificate Parsing Server (XPS): automates the extraction process  Disadvantages – High storage requirements – Security Issue • Data integrity checking: matching is performed unsigned extracted attributes – Poor manageability • DIT Restructuring to support multiple certificate for an user 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Directory Information Tree of Attribute Extraction  DIT Restructuring for storing multiple certificates for a user DN: o=IBM,c=US DN: cn=John,o=IBM,c=US DN: x509Serial=12345,cn=John,o=IBM,c=US cn:John uid=123456 userCertificate: MF4… x509Serial: 12345 x509Issuer: cn=CA,o=IBM,c=US … (a) DIT (b) DIT of Attribute Extraction 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Example Component Matching Filter User Userrequest requeststatement statement: : “Find “Findaacertificate certificatewhose whosesubject subjectisiscn=John,o=IBM,c=US cn=John,o=IBM,c=USand andkeyUsage keyUsageisisnon-re non-re pudiation" pudiation" New Matching Rule (userCertificate:componentFilterMatch := and:{ Component Reference item:{ component “toBeSigned.subject”, rule distinguishedNameMatch, Component Filter value “cn=John,o=IBM,c=US” }, item:{ component “toBeSigned.extension.*.extnValue.(2.5.29.15)”, Component Assertion rule bitStringMatch, value ‘010000000’B } } ) Component Assertion Value: BIT STRING in GSER 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 ASN.1 Awareness and Component Matching  ASN.1 awareness of LDAP directory servers – Ability to utilize the structural information of an ASN.1 type. – Understand how to construct complex types by combining basic types and composite types of ASN.1  Component matching for ASN.1 awareness – Define how to describe component filter and assertion for components – Define how to reference a component : component reference – Define a generic way of matching among components at an ASN.1 level – Generic String Encoding Rule (GSER) • Introduce structure information into UTF-8 based string encodings • The value of component assertion is encoded in GSER 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Generic String Encoding Rule  Define UTF8 string encodings rule for basic ASN.1 types and composite ASN.1 types – INTEGER, BOOLEAN, OCTET STRING etc – SEQUENCE, SET, CHOICE, etc toBeSigned toBeSigned ::::==SEQUENCE SEQUENCE{ { { version 2, version version [0] [0]EXPLICIT EXPLICITVersion VersionDEFAULT DEFAULTv1, v1, serialNumber CertificateSerialNumber, serialNumber 12345 , serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, signature { algorithm 1.2.840.113549.1.14, parameters NULL}, signature AlgorithmIdentifier, issuer Name, issuer Name, issuer {{type cn, value IBM trust} , {type o, value IBM},{type c, value US}}, validity Validity, validity Validity, subject Name, validity {notBefore {2004 01 13 18 59}, notAfter {2005 01 13 18 59} }, subject Name, subjectPublickKeyInfo subjectPublickKeyInfosubjectPublicKeyInfo, subjectPublicKeyInfo, … … … } extensions extensions [3] [3]EXPLICIT EXPLICITExtensions ExtensionsOPTIONAL OPTIONAL }} Example GSER Encodings of Certificate Certificate ASN.1 type 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Our Framework of Component Matching Enabled OpenLDAP 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 An eSNACC Compiler and a GSER Back-end  What does the compiler do? – Compile ASN.1(Abstract Syntax Notation One) modules into • ASN.1 equivalent C data structures • Routines to convert to/from the internal (C or C++) representation from/to the corresponding BER/DER formats  GSER back-end – Generate GSER encoding/decoding functions of given ASN.1 types GSER Encodings Certificate ASN.1 Type { {version versionv1, v1,serialNumber serialNumber12345 12345,signature ,signature{… {…},}, toBeSigned toBeSigned ::::==SEQUENCE SEQUENCE{ { “issuer “issuercn=CA,o=ibm cn=CA,o=ibm…… } } version [0] EXPLICIT Version DEFAULT v1, version [0] EXPLICIT Version DEFAULT v1, serialNumber serialNumber CertificateSerialNumber, CertificateSerialNumber, signature AlgorithmIdentifier, signature issuer AlgorithmIdentifier, Name, Decoding Encoding issuer Name, DecToBeSigned(…) EnctoBeSigned(…) validity Validity, validity Validity, typedef subject subject Name, Name, Compiling typedefstruct structtoBeSgined{ toBeSgined{ subjectPublickKeyInfo subjectPublicKeyInfo, AsnInt version; subjectPublickKeyInfo subjectPublicKeyInfo, AsnInt version; AsnInt …… AsnIntserialNumber; serialNumber; extensions [3] EXPLICIT Extensions OPTIONAL struct AlgorithmIdentifier* signature; extensions [3] EXPLICIT Extensions OPTIONAL struct AlgorithmIdentifier* signature; }} struct Name* issuer; struct Name* issuer; …… }} C internal data structure 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Component Representation  Component – The arbitrary part of attribute value that can be referenced or identified by Component Reference  Component representation – Preserve ASN.1 structure information in the internal representation – Two parts • Data value – Value in a C internal data structure • Component descriptor for its value processing – Value-specific encoder/decoder/matching rule/extract – Component tree • All components are comprised of one tree  Component extraction – Extract referenced components from a component tree – Generated by the eSNACC ASN.1 compiler automatically 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Component Matching Implementation  Component assertion (GSER encoded) – An assertion about the presence, or values of, components within an ASN.1 value – Component reference • Identifying the component part of a ASN.1 value. – Matching rule – Component assertion value in GSER  Component filter (GSER encoded) – An “and”, “or”, “not” expression of ComponentAssertion, evaluates to either TRUE, FALSE or Undefined  Component equality matching rule – allComponentsMatch and refined matching rules – Generated by the eSNACC ASN.1 compiler automatically 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 User Userrequest requeststatement statement: : “Find “Findaacertificate certificatewhose whosesubject subjectisiscn=John,o=IBM,c=US cn=John,o=IBM,c=USand andkeyUsage keyUsageisisnon-re non-re pudiation" pudiation" New Matching Rule (userCertificate:componentFilterMatch := and:{ Component Reference item:{ component “toBeSigned.subject”, rule distinguishedNameMatch, Component Filter value “cn=John,o=IBM,c=US” }, item:{ component “toBeSigned.extension.*.extnValue.(2.5.29.15)”, Component Assertion rule bitStringMatch, value ‘010000000’B } } ) Component Assertion Value: BIT STRING in GSER Example Component Filter 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Overall Operational Steps in Our Framework 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Component Matching Optimization  Attribute/matching rule aliasing – Backward compatibility for legacy clients – Avoid expensive extensible filter processing userCertificate:componentFilterMatch =: item:{ x509certificateSerial=12345678 component “toBeSigned.serialNumber”, attribute aliasing rule IntegerMatch, value 12345678 } Aliased Component Alias Attribute Matching Rule Attribute Reference x509certificateSerial userCertificate toBeSigned.serial integerMatch x509certificateIssuer userCertificate toBeSigned.issuer distinguishedNameMatch Example Attribute Aliasing Table 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Component Matching Optimization Contd.  Component indexing – Boost search performance by supporting component-level indexing • Indices on serial number, issuer name, version, etc  Component caching – Eliminate certificate (DER) decoding overheads • 72usec/certificate : Intel Xeon 2.8GHz – Cache decoded internal representations of a certificate 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Performance Evaluation  Directory population – OpenSSL and Component Matching • DirectoryMark generated entries: 100k and 500k – Attribute extraction • Used XPS (OpenLDAP patch) to extract attributes  System under test (SUT) – IBM xSeries 445 servers : 4-way Intel Xeon 2.8GHz with 12GB memory – Network connection: 1 Gbps Ethernet – Server: OpenLDAP 2.2.2 and Berkeley DB 4.3 – Clients: DirectoryMark scripts (8-way IBM xSeries 445 servers)  Performance measurement – Search throughput (operations/sec) • Matching against serialNumber – 100K entry add performance 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Performance (Population / Search) Directory Population Performance Component 100K entries OpenSSL Attribute Extraction Matching Time (sec) 178 167 815 DB Size(Mbytes) 234 234 410 Directory Search Performance 20.0K 4.0K CM- No Cache CM OpenSSL Attribute Extraction CM- NoCache CM OpenSSL Attribute Extraction 18.0K 3.5K 16.0K 3.0K 14.0K 2.5K operation/ sec operation/ sec 12.0K 10.0K 2.0K 8.0K 1.5K 6.0K 1.0K 4.0K 0.5K 2.0K 0.0K 0.0K 1 4 8 15 20 1 4 8 15 20 # of Clients # of clients 100k entries, DB cache = 1GBytes 500k entries, DB cache = 200MBtyes 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 Summary  Enhance LDAP-PKI interoperation for flexibility and manageability  Component matching enabled OpenLDAP server – ASN.1 awareness • Supports any ASN.1 type from its specification • Supports GSER in attribute / assertion values – Component Matching • Supports searching of any Certificate attributes – First implementation of component matching in a pure LDAP server  Component optimization techniques – Component aliasing, component indexing, and component caching – Enable high-performance, scalable LDAP certificate repository  Component matching enabled OpenLDAP will help to use PKC more flexibly in many PKI applications of Internet2, OASIS, GRID… 4th PKI R&D Workshop, Gaithersburg MD, April 19 th 2005 PKI without Revocation Checking Karl Scheibelhofer Institute for Applied Information Processing and Communications Graz University of Technology, Inffeldgasse 16a, 8010 Graz, Austria Email: karl.scheibelhofer@iaik.tugraz.at than a second. Certificate based PKIs have Abstract been designed based on the assumption that Current X.509-based PKIs are typically network connectivity is a limited and expen- complex. One of the most critical parts is sive resource (see III in [13]). revocation checking. Providing revocation information is a big effort for CAs, and for This paper considers current certificate clients it is even more costly to get all re- and revocation checking practice in the light quired revocation data. This work provides of ubiquitous access to the Internet. The a performance calculation of two CA setups focus is on X.509 certificates [1] and current with CRLs, delta CRLs and OCSP as revo- revocation checking techniques like CRLs cation checking mechanism. The enhance- and OCSP [2]. Based on this analysis, we ment of this work is the proposal to avoid propose a simple way to make certificate revocation checking by issuing certificates handling and validation easier in a net- on-line and only retroactively. An analysis worked environment. The proposed ap- shows that this approach performs at least proach is an on-line certification service. as good as OCSP and much better than The CA issues a new certificate each time CRLs. In addition, this solution reduces the the key owner uses the key. We will show complexity of PKI significantly. that this requires not more effort than OCSP, neither on the CA side nor on the client side. Moreover, it reduces the overall complexity Introduction of the system and provides up-to-date status Today, most computers are connected to information about the key. This can be seen a network. Usually, this is a corporate net- as a special version of short-lived certifi- work, a home network or a campus network, cates, which have been proposed several and this network is commonly connected to times (e.g. [9]). Unlike short-lived certifi- the Internet through firewalls and routers. cates, here, the validity time degrades to an Pure off-line systems are the exception instant in time which lies in the past. Thus, rather than the rule nowadays. Even if many the statement made by the CA through a computers are only on-line from time to certificate can be definitive, which makes time, they attach to a network on a regular revocation a less critical issue in many basis. This holds for notebooks, PDAs and cases. There is no need for revocation smart phones. However, with most of these checking of such certificates; the certificate devices, it is easy to go on-line. The Internet already contains the status information. becomes ubiquitous: Ethernet at the office, cable modem or DSL at home, WLAN at Certificate Validity campus, airports and rail stations, 3G in cit- ies and more to come. Network connectivity Each X.509 certificate contains a validity is no scarce resource any longer, as well as period, which is a time interval determined performance. Even smart phones can create by a start date and an end date. The start date and verify digital signatures in much less is normally the time at which the CA issued the certificate. The end time is often calcu- cial extension to its response messages, the lated as a fixed offset from the start time, archive cutoff extension. Thus, OCSP re- e.g. start time plus one year. One year is a sponders may extend the period through typical validity frame for a public-key cer- which status information about certificates is tificate. The certificate validity is often in- available. However, it does not really extend terpreted as "this certificate is valid during the validity period in the sense defined by this time interval unless it is revoked". How- PKIX because in practice, a certificate ever, PKIX [1] defines it differently: The owner cannot revoke a certificate which has certificate validity period is the time interval already expired. In consequence, relying during which the CA warrants that it will parties can get information about revocation maintain information about the status of the issues which happened within the certifi- certificate. On the first look, the two inter- cate's validity period, but they cannot get pretations seem to be similar, but there are revocation issues beyond this period. The subtle differences. The PKIX definition does CA does not offer such service for expired not imply any validity information. A cer- certificates. tificate can still be valid even beyond its validity period. The CA simply does not Revocation Checking guarantee to provide information about the In general, a certificate which is within its validity of this certificate outside this time validity period can be valid or revoked. A frame. The first interpretation does not ac- client cannot find out the status of the cer- cept a certificate which has been used out- tificate off-line. Finding out if a certificate is side its validity period, no matter, if other valid requires access to some network re- status information is available. In practice, source. This can be the current CRL on a the application of both interpretations ends web server or an OCSP responder. in the same results. The reason is that most CAs do not provide positive status informa- CRLs tion for certificates. This means, the CA tells clients what certificates are definitely re- CRLs are a problematic mechanism for voked, but only for certificates which are revocation checking. For the CAs they pro- within their validity period. For other certifi- vide a simple means with low requirements cates, the clients do not get any revocation concerning signature creation and security. information. If a certificate runs out of its For the relying parties who need to verify validity period, we call it expired. In case a certificates, CRLs are a pain. They are often considered certificate expired, clients have quite large, they often contain close to 100% no means to find out if the CA no longer irrelevant information and they usually pro- provides revocation information or if the vide no current revocation information. certificate has not been revoked. In other Consider SSL [4] server certificates from words, a client may or may not find out if an Verisign, Inc.. They contain a CRL distribu- expired certificate has been revoked before tion point referring to the location of the it expired. The client has no guarantee that current CRL. However, this CRL is about such certificates are listed on the CRL. 750 kByte. In consequence, most browsers work without revocation checking for server The situation is similar for OCSP. Since certificates. Downloading the CRL would OCSP responders may cache old CRLs, they take considerable time and would delay the may provide certificate revocation status HTTP transfer unacceptably long. beyond certificate expiration. A responder can indicate such support by adding a spe- CRLs have a validity period similar to the server could be replaced by a backup certificates. It is determined by the time at system. In case of a key compromise, how- which the CRL has been issued, called thi- ever, the administrator would need to revoke sUpdate, and the time at which the next the certificate immediately and inform all CRL will be issued latest, called nextUp- clients quickly. A delay of several days ap- date. According to PKIX, a client can cache pears intolerable. CRLs do not provide an a CRL until nextUpdate and rely on this efficient solution in this situation. Reducing information. However, it is apparent that a the caching time of CRLs does not offer a CRL cannot provide status information significant improvement either. The client newer than indicated in its thisUpdate field. may download the latest CRL for each cer- Caching the CRL is nice and provides a tificate validation issue, but this is impracti- benefit in some special applications, but for cal. It wastes bandwidth and introduces de- many applications, it does not make much lays, which are unacceptable for many ap- sense. System designers using cached CRLs plications. Moreover, the server which pro- should be aware of the fact that relying on vides the CRL would break down under the cached CRLs may produce load if all clients would download the cur- non-deterministic behavior for revocation rent CRL every time, at least in environ- checking. Consider a web server certificate. ments with a considerable number of certifi- The mentioned CRL has a validity period of cates and entries in the CRL. The waste of two weeks. Thus, in case of certificate revo- bandwidth in such configurations would be cation, clients will notice this revocation up enormous. to two weeks later and one week later on average if they cache the CRL as long as Almost all data in a CRL is of no interest possible. Until the cached CRL expires, the for the client. This is easy to see. The client client will consider the certificate as not re- is usually only interested in the status of a voked, even if it has already been revoked. single certificate. The CRL returns a list of This information simply did not yet propa- all revoked certificates in which the client gate to the client because the cached CRL can look up the concerned certificate. In has been used. Thus, the client will get a most cases, the certificate of interest will not different result for revocation checking the be listed in the CRL. Revocation is more an same certificate twice, even if checked with exceptional case than a common case. respect to the same time. This Common rates for certificate revocation are non-deterministic behavior can be a 5 to 10 percent, i.e. about 5 to 10 percent of show-stopper for certain applications; for all issued certificates get revoked before instance consider applications where relying they expire. This would mean that a client parties transfer noticeable volumes of money would find the certificate of interest on the based on a positive signature verification CRL in at most 1 of 10 (10 percent) or 1 of (including a certificate validation with revo- 20 (5 percent) cases. At most because a re- cation checking). voked signature or authentication certificate will typically only be used after revocation Usually, administrators would switch to a in case of a key compromise. If the certifi- new certificate even before they revoke the cate owner loses the private key, the certifi- old certificate. As long as there has not been cate is useless and cannot be used any a key-compromise, revocations may not be longer. Likewise, the legitimate owner that critical anyway. These cases can often would not use a certificate which has been be handled by organizational means. For revoked because of changed owner informa- example, the certificate can be updated, or tion. Key compromise will naturally be a scarce reason for revocation compared to - The issuer of the CRL could be different key-loss and change of subject information. to the issuer of the certificate. It may be As a result, a CRL will contain the con- difficult to make a trust decision and no cerned certificate even less frequently as user wants to do this manually (most us- calculated before. In effect, during a single ers do not even have the required back- certificate validation procedure, a CRL car- ground knowledge to do it). ries only a single bit of information for the client. The client wants to know if the con- - If the application has to verify a certifi- sidered certificate is valid (or was valid at a cate (which may already be expired) certain time). The answer can only be yes or with respect to a time in the past, it no (unknown can be considered as a third would need an old CRL. There is no alternative). Compared to such large CRLs standardized way to get an old CRL. The as mentioned before, which contain over standards only specify how to get the lat- 20000 entries, the waste of resources be- est CRL. comes obvious. This list can be extended by various bul- The PKIX standards also define so-called lets. These cases do not frequently appear in Delta CRLs. Their main goal is to reduce practice, but they are perfectly valid accord- bandwidth demand. Subsequent CRLs differ ing to the underlying standards. If a devel- only slightly in their contents compared to oper has to implement a system, which sup- their predecessor. Some new entries are ports this standard, the system needs to be added and some old may be removed, but able to handle these special cases as well, the vast majority of the entries will stay the even though they might never appear in same between two subsequently issued practice. As a result, developers may end up CRLs. Thus, the idea is to transfer only with a final system where many parts of the changes in the CRL most of the time. A certificate validation system are never really delta CRL refers to a complete CRL and just used. mentions the differences to this CRL, i.e. the added entries and the removed entries. Thus, For completeness, we should mention the client has the same information as if it that there are use-cases where CRLs are suf- would have two complete CRLs. Delta ficient and the required bandwidth is not that CRLs are rarely used in practice. The added critical. If the CRL does not contain many complexity is one of the reasons. entries, the lavished bandwidth is not that significant either. The size of the CRL can Revocation checking does only look that be decreased using different approaches. A simple on the first look. If one implements simple one is to use partitioned CRLs. Using the complete PKIX specification and con- this method, the CA splits the set of all is- siders all (or at least all practical) use-cases, sued certificates into groups of similar size. revocation checking based on CRLs can get The CA will issue an individual CRL for complex. Here are some reasons: each group of certificates. Thus, the certifi- cates, even though issued by the same CA, - There could be a different CRL for each will point to a different CRL location, de- revocation reason. In consequence, the pending on the group they belong to. For client would have to check each of these CAs which issue only a small number of CRLs. certificates, the CRL will generally stay small enough without segmentation. OCSP This is nice for OCSP service providers be- CRLs have been designed as an off-line cause it allows very simple implementations mechanism for revocation checking. An of an OCSP responder. In this case, the off-line mechanism cannot meet certain re- OCSP service is nothing more than a quirements for timeliness and efficiency. So front-end for the latest CRL. Consequently, what about on-line protocols? Does OCSP an OCSP service implemented this way in- perform better? It may. At least, it does not herits the problems inherent to CRLs except waste that much bandwidth in most cases. the bandwidth consumption. Remarkably, the bandwidth consumption of CRLs is the The basic idea of OCSP is simple. It is an biggest cost factor for big CAs as docu- on-line service which provides revocation mented in [11]. information about certificates to clients. When the client needs to validate a certifi- Revocation Checking in cate, it can send a request to an OCSP re- Practice sponder. The OCSP server answers with In practice, many systems do not perform information about the revocation state of the revocation checking at all. This has various certificate. Unfortunately, there are some reasons. Most web browsers do not check details which can make OCSP harder to use server certificates for revocation. The main than necessary. First, the client needs the reason seems to be the potentially long delay issuer certificate of the certificate of interest due to downloading the CRL. Many email because the hash of the issuer certificate's clients often perform no checking per de- public key is required in the OCSP request fault either. The long delay seems to be the message. Second, the response of the server reason once again. However, most applica- may not be as concrete as the client would tions at least offer options to enable revoca- need it to be. A normal OCSP response does tion checking. Some of them, for instance not provide positive certificate status infor- Microsoft Outlook 2002 or later, perform mation. OCSP responses have several prop- revocation checking per default. It is easy to erties which degrades their effectiveness in identify such email clients with enabled many use-cases: revocation checking because there often is a long delay if the user opens a signed or en- - The response does not say if the certifi- crypted email. Downloading the CRL takes cate is valid, it merely says that the cer- most of this time. tificate is not revoked. However, this can even mean that the certificate has never Only a few systems support OCSP. been issued.1 Mozilla is one of these few exceptions. Most web browsers and email clients do not sup- - The revocation information provided by port it, at least not without additional an OCSP server may not be up to date. third-party tools. On the CA side, the situa- tion is similar—not many of them run OCSP At a minimum, a client cannot expect to servers. Those who run an OCSP server of- get more information from an OCSP re- ten implement them based on CRLs rather sponder, as it can get from the latest CRL. than to base them on current status informa- tion. Third-party OCSP responders usually 1 The German ISIS-MTT [12] profile defines the have no other means than to base their re- CertHash extension for OCSP responses. A response sponse information on CRLs. Third-party containing this extension can provide a positive status OCSP responders have the advantage that information. they can provide revocation information for unless the CRL is very small which is typi- certificates from various CAs. On the other cally not the case. Verifying the signature of hand, users must configure their clients the status information—the signature on the manually to use external responders. In sen- CRL or on the OCSP response—is effec- sitive environments, it might be impossible tively the same effort for the client. The to rely on another external party; additional timeliness of the status information may also contracts have to be prepared, liability issues differ between CRLs and OCSP. An OCSP have to be clarified, and so on. responder may provide real-time revocation information, while a CRL always provides OCSP is capable of providing a better aged information, though, many OCSP serv- service to clients than CRLs can do. For the ers do not provide more current information provider side, OCSP requires additional re- than the CRLs do. sources. Since OCSP is an on-line service, it requires a reliable server system with a high Small CA Big CA level of security. The server has to sign its Certificates 1 000 1 000 000 responses with a private key. This key re- Certificate Users 1 000 1 000 000 Certificate Validity 1 1 quires the same security level as the key for [years] CRL signing does because it serves to pro- Revocation 10% 10% tect the same kind of information— Probability revocation information for the same certifi- Certificate 10 10 cates. Some simple investigations and calcu- Validations per lations show that OCSP shifts the demands Certificate [day-1] from network bandwidth to processing Table 1: Properties of the considered configura- power. tions Calculations can show some values for Table 1 shows the properties of two CA the performance estimation of CRLs and configurations which we will use as a basis OCSP for revocation checking. First, we for performance estimations. There are two sketch rough values for the required band- configurations—a small CA configuration width in certain environments. In addition, with thousand issued certificates, and a big we consider the number of required signa- CA with one million issued certificates. We ture creations on the server, which differs set the validity period of the issued certifi- significantly between CRLs and OCSP. On cates to one year, which is a typical value. In the client side, CRLs and OCSP have also addition, we assume that the number of cer- others impacts. If a client uses CRLs, it tificate users (users who validate certificates needs to cache CRLs. Without caching, from this CA) is roughly the same as the CRLs are a real performance and resource number of issued certificates. However, killer because the client would download the these two numbers can vary significantly in complete CRL for each revocation checking. practice; a CA issuing only server certifi- Some implementations do this intentionally cates for a few big web servers like Amazon, to ensure that they have the latest available eBay and Google would have a huge number revocation information. This practice cannot of users validating the certificates while the be recommended in general. If there is a number of issued certificates is small. For demand to get always the latest revocation the probability of certificate revocation, we information, OCSP is a better choice. In take 10%, i.e. the probability that a certifi- addition, processing a CRL is usually more cate will be revoked before it expires. This is costly than processing an OCSP response, also a quite common value in practice, but it name. For this additional data, we assumed may even be much lower, e.g. one percent. 250 Byte. If we take the small CA, for ex- We assume, that a user validates about 10 ample, the CRL would contain 50 entries on certificates per day, for example, verify 5 average3, which will result in a size of 2250 signed emails and encrypt 5 emails per day. Byte (50.40 + 250). The total number of These numbers set the frame for our short certificates and the probability of certificate investigations. They are typical values, even revocation determine the number of entries. though there are configurations for which Taking the 10 certificate revocation checks these values would look very dissimilar and per user and per day, every user downloads would result in quite different performance each issued CRL. This ends up in a network estimations. transfer volume of 2,1 MB per day for the small CA and 1900 GB per day (about 22 Small CA Big CA MB per second) for the big CA. This is a CRL Validity 24 24 noteworthy volume. Only big companies can [hours] afford such a network bandwidth, and often Signature 4 3 014 merely in a local network and hardly via the Creations [day-1] Internet. It is also a matter of costs. Would CRL Size [Byte] 2 250 2 000 250 CRL Downloads 1 000 1 000 000 you afford this for revocation checking only [day-1] if there are cheaper alternatives? Bandwidth 2,1 1 900 000 [MB/day] Moreover, these numbers can easily in- Table 2: Expected CRL Performance crease. The current numbers are based on an issuing interval of one day. In the worst Table 2 shows the expected performance case, clients get one-day-old revocation in- data for the two CAs using CRLs for revoca- formation. If the managers of a system de- tion checking. We took a CRL validity of 24 cide to increase the CRL issuing frequency hours. This is the time between the thisUp- to get a better timeliness, the increase of date and nextUpdate values in the CRL. The network transfer is inverse proportional. number of signature creations required on Reducing the CRL validity to the half (i.e. to the CA side is comprised of certificate and 12 hours) doubles the transfer volume. The CRL issuing—one signature per each cer- peaks of bandwidth consumption may be tificate and each CRL. For instance, the even much higher because we assumed small CA issues 3 certificates per day on evenly distributed download requests over average and 1 CRL, which requires 4 signa- time. In practice, peaks are very likely, for ture creations in total per day. Here, the cer- instance, in the morning when people start tificates account for most of these signatures working there will be a peak, while the because the CA issues CRLs infrequently. download rate will drop during the night. For calculating the CRL size, we took 40 Byte as the size of each CRL entry2. Despite the entries of the revoked certificates, each CRL contains additional data like the signa- ture, thisUpdate, nextUpdate and the signer 3 We get 100 entries in the worst case, which occurs 2 This consists of at least 13 Byte for the revocation if the CA issues all certificates at the same time (e.g. date, plus the serial number (e.g. a SHA-1 hash at the beginning of the year). If it issues the certifi- value), plus an overhead for the DER encoding of at cates continuously over the year, we could expect 50 least 6 Byte. In addition, there may be extensions for entries in each CRL, because on average a certificate the reason code or invalidity date. would be revoked after half of its validity period. delta CRL signatures are required addition- Small CA Big CA ally, while the number of signatures for base Base CRL 7 7 7 7 CRLs decreases at the same time because Validity the CA issues them only once a week. [days] Delta CRL 24 2 24 2 Validity As a result, we can see that the bandwidth [hours] consumption decreased significantly. In the Signature 4 15 3015 3025 case where delta CRLs are issued once a Creations day—which provides the same timeliness as [day-1] the full CRL case considered before—the Base CRL 2250 2250 2000250 2000250 transferred data volume dropped to 0,58 MB Size [Byte] Avrg. Delta 288 288 38606 38606 per day for the small CA and to 310 GB per CRL Size day for the big CA. This is a reduction of [Byte] about 73% and 84% respectively. Even if we Base CRL 143 143 142857 142857 reduce the validity period of the delta CRLs Downloads (and increasing the timeliness of the infor- [day-1] Delta CRL 1000 10000 1000000 10000000 mation at the same time) in the Big CA Downloads setup, the load on the network remains lower 4 [day-1] than with full CRLs. Only for the small CA, Bandwidth 0,58 3,1 310 000 640 000 the network load is higher than in the full [MB/day] CRL case, 3,1 MB per day compared to 2,1 Table 3: Expected Delta CRL Performance MB per day. Delta CRLs can reduce the bandwidth Small CA Big CA consumption significantly. Table 3 shows Signature Creations 10 003 10 003 014 that the CA can issue delta CRLs even more [day-1] frequently while the bandwidth consumption Request Size [Byte] 250 250 is still much lower than for full CRLs. To Response Size [Byte] 1 250 1 250 get comparable results, we included a delta Bandwidth [MB/day] 14,3 14 305 Table 4: Expected OCSP Performance CRLs case with the same timeliness con- straints, which we had for the full CRL case; Table 4 gives a performance estimation i.e. there is one column for the small CA and for an OCSP responder for our two CA con- for the big CA for which the delta CRL va- figurations. This table is simpler because lidity is 24 hours—the same value as the there is nothing such as a validity period. CRL validity in Table 2. To get an impres- Even if the OCSP responder gets its status sion how the results would change due to a information from CRLs, it makes no per- reduction of the delta CRL validity, we formance difference, which would reflect in added another column for each CA with the table. If the OCSP responder gets its smaller delta CRL validity—two hours in status information from CA database di- this case. In contrast to the full CRL case, rectly instead of from CRLs, the CA could with delta CRLs, the CA has to create a abandon CRLs completely. In addition, it similar number of signatures. Only a few would enable the OCSP responder to pro- vide real-time status information and posi- 4 Note that the number of delta CRL downloads per tive status responses (this requires a day will not be higher than the overall number of non-standard extension like the CertHash certificate validations per day, which is the product of certificate validations per day (per certificate) and the extension in [12]). In contrary to the CRL number of certificates. case, for OCSP the bandwidth consumption increases linearly with the number of certifi- validations and the timeliness requirements cate validations. With CRLs, the client for revocation information. Up to now, time- downloads a CRL and does all revocation liness requirements seem to have a low pri- checking based on it until it expires. With ority for CAs because there are many CAs OCSP, the client has to get a separate OCSP which do not offer OCSP responders and response for each certificate validation. The those of which who implement their servers caching of responses gives no benefit unless to provide no more current revocation in- the client always validates the same certifi- formation than the latest CRL does. It is cates. unclear if there is not enough demand from the customers for up-to-date status informa- As we can see in the table, the bandwidth tion, or if the CAs are reluctant to implement consumption is quite affordable. While it is better OCSP servers. a little higher for the small CA, it is smaller by an order of magnitude for the big CA. Proposal for an on-line PKI For the small CA, the OCSP responder pro- Certification Authorities issue certifi- duces 14,3 MB traffic per day compared to cates. Users who receive such a certificate 2,1 MB with full CRLs and 0,58 MB and 3,1 need to find out, if the data in the certificate MB with delta CRLs. In large environments, is valid with respect to a certain time. For the difference is tremendous. Here, the digital signatures, this is the time of signa- OCSP responder causes about 14 GB net- ture creation. In case of encryption, it is usu- work traffic per day compared to 1900 GB ally the current time. The application per- with full CRLs and 310 GB and 640 GB forms revocation checking to find out if the with delta CRLs. In addition, an OCSP re- certificate is valid. Other steps are also re- sponder can give real-time status informa- quired, but applications can typically proc- tion—CRLs cannot. These 14 GB per day ess them with locally available data. Certifi- (0,17 MB per second) are an affordable cate chain building, for example, is often bandwidth, not only for a corporate network rather easy because most protocols like se- but also for Internet connections. cure email and SSL/TLS recommend send- These simple calculations already give a ing the complete certificate chain anyway. clear impression of the scalability of the Fortunately, most implementations stick to different revocation mechanisms used in this recommendation. practice. OCSP scales much better than Is revocation checking always required? CRLs. As well, OCSP can provide more If we assume that the start of the validity current revocation information than CRLs. period of a certificate corresponds to the For small CAs, CRLs may cause slightly time when the certificate has been issued, an less network traffic, but also provide less application would not need to check a cer- timely status information. OCSP can show tificate for revocation with respect to this its advantages in large environments, where time. In fact, a certificate does not say any- it can reduce the network traffic massively. thing about its validity. Even the validity However, all these calculations are valid period is only defined to specify the time only for two simple but reasonable setups. interval during which the issuing CA guar- The results can vary depending on various antees to provide status information. Cur- factors of the environment, including the rently, there are new standards for certificate number of issued certificates, the number of validation on the way. One of the most certificate users, the number of certificate prominent ones is the Simple Certificate Validation Protocol, short SCVP. The PKIX each time instant at which the signer creates working group develops this standard. It a signature. An important difference is that should enable clients to off-load the com- the validity period of such certificates would plete task of certificate validation. The client always be in the past (with respect to the sends a request to the service for validation issuing time) or would at most extend to the of a certain certificate. As a result, it gets the current time. validation result. This approach has several advantages. Developers with no PKI knowledge may First, there is no need for additional revoca- ask, if we need certificates at all. This is a tion checking. The issued certificate would legitimate question. The client has to trust already transport all information to the re- the validation server anyway to provide cor- cipient—the signer was the legitimate owner rect results, and it does not do any process- of this key at the signing time. For encryp- ing of the certificate itself any longer despite tion, the time of interest is the current time, picking the public key and the identifier of and the sender would go for a certificate for the key owner. In many cases, it would be the intended recipient. sufficient to add the signer’s name and the signature verification key to a signature. The One apparent disadvantage is the required verifier could then ask the validation server on-line access for the client. Having a closer if this signer was the legitimate owner of the look, the requirements are the same as if the verification key at the time of signature crea- user would have to perform revocation tion. The validation server could still employ checking with up-to-date status information. certificates for its internal processing and This is also only possible with on-line ac- select the appropriate ones. However, if the cess. Users and applications can still use old CA runs the validation server, there seems to certificates if they do not have such high be no point in using certificates in the tradi- security demands. Here, the decision is up to tional way. Accessing databases seems to be the users if they accept out-dated informa- simpler and more efficient. The signer could tion about the binding between alleged key add a link to the certification authority to the owner and key or if they go for reliable and signature to support the client in selecting definitive information. the right one for validation. It may even make sense to have more than one authority An additional improvement is the re- at the same time. The recipient can pick a duced complexity. Only one format is re- trusted one or may validate with several or quired for certificates, no additional format all of them to increase the trust in the result. for CRLs or OCSP or any other validation It would also be possible that the signer al- service. The existing certificate format could ready gets a signed validation result from the even serve as the request format for this authority at the time of signature creation. on-line certification service. The request The validation result is actually nothing else would not need a signature though. The re- than a certificate. The recipient can still do sponse would be just a certificate. The valid- its own validation on demand. Thus, the ity period of this certificate would be just a same format can be used. All we need is an single time instant or maybe a period in the on-line service for certificate issuing from past. For the past, the certification authority the CA. The requirements for such a service would be able to provide definitive answers. would be pretty much the same as for an Thus, revocation may not be required at all, OCSP service. The CA would issue a new in the sense it is used today. certificate for each signature, or at least for Business cases would also be simpler and voke. After revocation of the binding, the more flexible with this approach. A com- CA would simply no longer issue certifi- mercial CA would be able to charge on a cates via its on-line certification service for per-use basis, for example, per issued sign- this combination of key and user. There is ing certificate. Since the CA does not need no need to revoke any old certificates it is- to run an additional revocation checking sued before because the certificate state- service, the resource planning is also easier ments refer to a time in the past before the and more predictable. Just imagine that Mi- revocation took place. crosoft enables certificate revocation check- ing using CRLs per default in their Internet What is the performance of such a simpli- Explorer. Commercial CAs would face fied on-line certification PKI? The band- tough times providing their large CRLs for width consumption is actually the same as millions of clients in the world. for OCSP, assuming that the requests and responses are roughly of comparable size. The workflow for setting up a relation or This seems to be a reasonable assumption. contract between the user and the CA can remain the same. The CA can issue a first Small CA Big CA certificate during this initial phase. Even Signature 10 000 10 000 000 Creations though the client does not really need this [day-1] certificate, it may help ensuring compatibil- Request Size 500 500 ity with existing applications. The client [Byte] could even use just a self-signed certificate Response Size 1 000 1 000 instead because it also includes the required [Byte] public key and name. Moreover, a self- Bandwidth 14,3 14 305 [MB/day] signed certificate can serve as a proof of Table 5: Expected performance for on-line certi- possession during the registration. If the fication client registers its public key at several CAs, it would not need to have several certifi- Table 5 shows the expected performance cates. There is nothing wrong with the regis- values at the CA side. The number of re- tration of the same user-to-key binding at quired signature creations is even slightly several CAs. It would only cause different lower than for OCSP because for OCSP the CAs to vouch for the same statement. In CA has to issue certificates and OCSP re- fact, this is an increase of security because it sponses. Here, we only have one signature may be possible that a single CA makes mis- for each certificate, the total number of takes, but it is less likely that several inde- which is the same as for OCSP responses. In pendent CAs make the same mistake. practice, the situation may be even better because clients typically do not cache OCSP The client actually needs just its identifier responses. Thus, they get an OCSP response (something like the subject name) and its each time they validate a certificate, even if key-pair. For further communication with they validate the same certificate with re- the CA, it can use this signature key and the spect to the same time. In the case of on-line identifier to authenticate the requests to the certification, when the signer already at- CA. A request can be for lengthening the taches the certificate to the signature, the contract with the CA or for revocation of a verifier may not ever need to go for a new key-to-identifier binding. Note that there is certificate. no revocation of a single certificate any longer because there is no certificate to re- For the big CA, the on-line certification They only need to handle the certificate service needs to perform 10 million signa- format, which can remain the same as al- ture creations per day, which are about 116 ready used in current systems. As a result, signature creations per second. This is an existing protocols like S/MIME [5] and amount, which modern server systems can SSL/TLS [4] can run without modification. easily process with pure software implemen- Some other protocols can even be simplified tations of cryptographic operations5. An because there is no need to support CRLs, on-line certification system would use se- OCSP and other revocation checking for- cure crypto hardware anyway for sheer secu- mats and protocols any longer. rity requirements. Modern hardware security modules (HSMs) are typically able to per- The service’s signature key is an attrac- form several hundred operations per second. tive target for attacks. This is a drawback, There are some HSMs available which can even though it is manageable with dedicated create several thousand signatures per sec- security devices. If an adversary can get the ond,6 and there are crypto processors which signature key of the service, it can issue cer- can perform several ten-thousands per sec- tificates at will. Current CAs often issue ond7. Thus, even for large CAs, an on-line certificates off-line and just issue revocation certification service seems to be feasible information on-line. Getting the signature with off-the-shelf hardware. key of the revocation service is not sufficient for issuing certificates, though the ability to Compared with CRLs and delta CRLs, issue wrong revocation information may on-line certification is a clear tradeoff be- allow attacks with similar severe effects. tween network bandwidth and processing power. On small-scale PKIs, on-line certifi- Conclusion and Further cation can require even more bandwidth than CRLs, but in large-scale PKIs, it per- Work forms equally well as OCSP. At the same During this work, we analyzed a few time, on-line certification can provide the typical PKI setups. Not surprisingly ([11]), it latest key status information, which an turned out that CRL-based revocation check- OCSP responder can also do, but CRLs and ing consumes a lot of bandwidth, especially delta CRLs cannot. for large CAs with many certificates and many users. For the proposed type of on-line On the client side, on-line certification certification, the requirements for the signa- can bring a significant reduction of com- ture creation performance are higher than for plexity because additional revocation check- CRLs, but they are at most as high as for an ing is no longer required. Moreover, clients OCSP responder. Unlike CRLs and certain need to handle less different data formats. OCSP responders, on-line certification pro- vides always the latest status information. This approach also reduces the complexity 5 For example, OpenSSL 0.9.7d compiled with as- of PKI systems because it eliminates the sembler optimizations on an AMD Opteron 146 with need for additional revocation checking, and 2 GHz performs about 900 signature creations per second using RSA 1024 bit keys (using CRT). in consequence, there is no need to support 6 The Sun Crypto Accelerator 4000 PCI Card can additional formats and protocols like CRLs create 4300 RSA signatures per second with 1024 bit and OCSP. In summary, the system re- keys using CRT. quirements regarding bandwidth and proc- 7 A NITROX Security Processor from Cavium Net- essing performance are comparable to works can perform up to 40 000 RSA signatures per second with 1024 bit keys using CRT. OCSP. Thus, existing hardware and software components are sufficient to implement an While recent work often increases the on-line certification system. overall complexity of PKI systems and thus diminishes its attractiveness, on-line certifi- On-line certification has some neat prop- cation can offer a real reduction of complex- erties, which makes it appealing to certain ity while improving utility. business cases. A pay-per-use scheme seems to be easy to implement. Its behavior is also References better predictable than that of current sys- [1] Housley, R., Ford, W., Polk, W., Solo, tems, which include separate revocation D.: Internet X.509 Public Key Infra- checking. Overall, the introduction of an structure, Certificate and CRL Profile. on-line certification service is more of a The IETF, RFC 3280, April 2002, avail- technical nature than an organizational one. able online at Thus, the existing organizational environ- http://www.ietf.org/rfc/rfc3280.txt ment can often remain unchanged. Even [2] Myers, M., Ankney, R., Malpani, A., many parts of the technical equipment can Galperin, S., Adams, C.: X.509 Internet remain unaffected or may require only small Public Key Infrastructure, Online Cer- adaptations. On the client side, the reduction tificate Status Protocol – OCSP. The in complexity is even more evident. This can IETF, RFC 2560, June 1999, available online at make PKI attractive even for such environ- http://www.ietf.org/rfc/rfc2560.txt ments where current PKI systems would [3] Adams, Carlisle, Lloyd, Steve, “Under- entail an unacceptable increase of complex- standing the Public-Key Infrastructure”, ity. New Riders Publishing, ISBN: 157870166X The next step towards an on-line certifi- [4] Dierks, T., Allen, C.: The TLS Protocol, cation service would be the more detailed Version 1.0. The IETF, RFC 2246, Janu- specification of a protocol. Such a service ary 1999, available online at would have to be as simple as possible. A http://www.ietf.org/rfc/rfc2246.txt prototype implementation as a proof-of- [5] Ramsdell, B. (Editor): S/MIME Version concept would also help to get a clearer im- 3 Message Specification. The IETF, pression of the advantages and disadvan- RFC 2633, June 1999, available online tages of this approach. It would also allow at http://www.ietf.org/rfc/rfc2633.txt benchmarking in different environments and [6] Doyle, P., Hanna, S.: Analysis of June use-cases. Measured values from real im- 2003 Survey on Obstacles to PKI De- plementations are more convincing than ployment and Usage. The OASIS Public theoretical calculations. Key Infrastructure (PKI) Technical Committee (TC), Version 1.0, 8 August Two important issues have not been con- 2003, available online at sidered yet. The first is the setup of trusted http://www.oasis- root keys. Even though, the same techniques open.org/committees/pki/pkiobstaclesju as for the setup of trusted root certificates ne2003surveyreport.pdf are applicable, simpler and more elegant [7] Myers, M.: Revocation: Options and mechanisms are desirable. The second is the Challenges. Financial Cryptography process of revocation itself, i.e. the actions 1998, Springer-Verlag Berlin Heidel- berg 1998, LNCS 1465, pp. 165-171. the key owner can take to notify the CA [8] Cooper, D.: A Model of Certificate Re- about revocation. Current systems solve this vocation. Proceedings of the Fifteenth issue unsatisfactorily. Annual Computer Security Applications Conference (ACSAC), pages 256-264, December 1999. [9] Rivest, R.: Can We Eliminate Certificate Revocation Lists? Financial Cryp- tography 1998, Springer-Verlag Berlin Heidelberg 1998, LNCS 1465, pp. 178- 183. [10] Fox, B., LaMacchia, B.: Online Certifi- cate Status Checking in Financial Trans- actions: The Case for Re-issuance. Fi- nancial Cryptography 1999, Springer- Verlag Berlin Heidelberg 1999, LNCS 1648, pp. 104-117. [11] Berkovits, S., Chokhani, S., Furlong, J., Geiter, J., Guild, J.: Public Key Infra- structure Study, Final Report. Produced by the MITRE Corporation for NIST, McLean, Virginia, April 1994. [12] Common ISIS-MTT Specifications for Interoperable PKI Applications from T7 & TeleTrusT. Version 1.1, 16 March 2004, available online at http://www.isis-mtt.org [13] Kohnfelder, L.: Towards a Practical Public-Key Cryptosystem. Bachelor Thesis, MIT, May 1978. [14] Ellison, C.: Naming and Certificates. Proceedings of the tenth conference on Computers, freedom and privacy, pp. 213-217. Toronto, Ontario, Canada, April 2000. Delegation Issuing Service for X.509 D.W.Chadwick, University of Kent, Canterbury, CT2 7NZ, England by its superior AA, and may delegate these Abstract further to subordinates (AAs or end entities). This paper describes the concept of a A subordinate who is not allowed to delegation issuing service (DIS), which is a delegate further is termed an end entity. In service that issues X.509 attribute the normal situation all privilege holders certificates on behalf of an attribute (AAs and end entities) are allowed to assert authority (typically a manager). The paper the privileges that are delegated to them. defines the X.509 certificate extensions that are being proposed for the 2005 edition of However, in some situations a privilege X.509 in order to implement the DIS holder may be allowed to delegate the held concept, as well as the additional steps that a privileges to a subordinate, but may not be relying party will need to undertake when allowed to assert the privileges itself. An validating certificates issued in this way. example might be an airline manager who The paper also presents our initial assigns privileges to pilots to fly particular experiences of designing a DIS to add to the aircraft, but is not allowed to fly the aircraft PERMIS authorization infrastructure. The himself, or a hospital manager who assigns paper concludes by reviewing some of the privileges to doctors on duty but is not previous standards work in delegation of allowed to assert these privileges himself. authority and anticipating some of the Whilst the X.509 standard recognizes this further standardization work that is still scenario, it offers no support for this in the required in the field of privilege ACs that can be issued to these AAs i.e. management. there is no way of signaling to a relying party (RP) that an AC holder may not assert 1. Introduction the privileges contained in the AC that it The 2000 edition of X.509 [1] defines a holds. This deficiency needs rectifying. Privilege Management Infrastructure (PMI) based on attribute certificates (ACs). Work is now progressing towards issuing Attribute certificates are very similar to the 2005 edition of X.509, and another public key certificates (PKCs) but hold delegation scenario has been identified in privileges (as attributes) instead of public the draft amendment [2] to X.509(2000). keys. In the X.509 PMI model, the root of This concerns the use of a delegation service the PMI is termed the Source of Authority to issue ACs on behalf of other AAs. The (SoA), and subordinates are termed delegation issuing service (DIS) concept Attribute Authorities (AAs). Delegation of recognizes that in some organizational Authority passes down the chain from SoA contexts, it might be preferable for a to AA to subordinate AAs in much the same manager (an AA) who wishes to delegate way as the authority to issue public key authority to a subordinate, be not certificates passes down a PKI certification empowered to issue the X.509 AC herself, authority hierarchy from the root CA to but rather should request a DIS to issue the subordinate CAs (see Figure 1A). A AC on her behalf. subordinate AA is given a set of privileges Points to AC holder Points to issuer SOA Bill SOA Bill Points to Issued On Issues Behalf Of AC to Issues AC to Issues AC to AA Alice AA Alice Delegation Issues AC to Issues Issuing AC to Service Bob End End Bob Entity Entity Figure 1A. Normal Figure 1B. Delegation of Authority using a Delegation of Authority Delegation Issuing Service Thirdly, the manager does not need to hold 1.1 Advantages of a DIS and maintain her own private signing key, The benefits of using a delegation issuing which would be needed if the manager were service instead of AAs issuing X.509 ACs to issue and sign her own ACs. Only the DIS themselves are several. Firstly, the DIS can needs to have an AC signing key. This could support a fully secure audit trail and be a very important feature in organizations database, so that there is an easily accessible that use mechanisms other than PKIs for record of every AC that has been issued and authentication such as biometrics, user revoked throughout the organization. If each names and passwords, or Kerberos etc. manager were allowed to independently Finally, if the DIS is given its own AC by issue their own ACs, then this information the SOA, it can replace the (set of) would be distributed throughout the manager’s AC(s) in the AC validation chain organization, making it difficult or and therefore decrease the complexity of AC impossible to collect, being possibly badly chain validation. The AC chain length or never recorded or even lost. Secondly, the would always be two when the DIS issues DIS can be provided with the organization’s the ACs to end entities, whereas it would be delegation policy, and apply control of arbitrary length when the managers issue procedures to ensure that a manager does the ACs themselves. Also less CRLs will not overstep her authority by issuing greater need to be issued – only the DIS will need to privileges to subordinates, or even to herself, issue a CRL rather than each manager. This than the organization’s policy allows. will further simplify AC chain validation. 1.2 DIS Deployment Models 1.3 Disadvantages of a DIS Two deployment models for the DIS are As mentioned above, in PKI (and AC PKI) envisaged in the 2005 draft amendment [2]. modes, AC chain validation is more In both models the DIS is empowered to complex when a DIS issues the ACs. issue ACs on behalf of other AAs, by being Another potential disadvantage of a DIS is issued with its own AC by the SoA. This AC that the single CRL issued by the DIS could confers on the DIS the authority to issue get very large, unless distribution points are ACs on behalf of other AAs. This used. A large CRL can adversely affect the empowerment model is similar to the PKI performance of AC chain validation. concept of an indirect CRL issuer, whereby Further, when cross certification between an entity is given the authority to issue PMIs takes place, in PMI mode there is a CRLs on behalf of a CA. In the first DIS loss of granularity since it has to be the DIS deployment model (which we have called that is cross certified rather than any of the the AC PKI mode), a privilege holder AAs that are trusted. But perhaps the biggest requests the DIS to issue privileges on its disadvantage of using a DIS for some behalf, but the DIS does not actually hold applications is that the AC signing key the privileges itself. The AA tells the DIS should be online and ready to be used to which privileges to delegate. In the second sign ACs when requested. In some highly deployment model, the DIS is actually given secure systems this would be unacceptable. the privileges to be delegated by the SoA (we have called this the PMI mode). 1.4 Paper Contents However, the 2005 draft amendment had no This paper describes proposed extensions to mechanisms for implementing either of the 2000 edition of X.509 that can be used to these deployment models. implement the DIS model for delegation of authority, as well as rectify the 2000 In our research and design of a DIS service deficiency that there is no way to signal that for PERMIS [5], we have also identified a an AA holds a privilege for delegation but is third deployment model in which the DIS is not allowed to assert the privilege. These not given an AC, but has its own PKI key extensions have recently been included as pair for signing the ACs its issues, with part of the revised draft amendment to empowerment flagged in the public key X.509(2000). certificate (we call this the PKI mode). The DIS now only needs to authenticate the AAs The rest of this paper is structured as and issue ACs on their behalf, without follows. Section 2 describes the X.509 validating the contents of the ACs. extension that can be used to signal that a Furthermore, the users do not need to have privilege holder is not allowed to assert the their own PKI key pairs. This simplifies the privileges that it holds. This corrects the design and deployment of the DIS service, deficiency in the 2000 edition of X.509. but the downside is that it complicates the Section 3 describes the X.509 extensions process of AC chain validation by the that can be used to implement the DIS relying parties due to the delegation model. Section 4 describes how relying indirection introduced by the DIS, as parties will need to use these new extensions described later. in order to validate ACs issued by a DIS. Section 5 describes how we are implementing the DIS in PERMIS. Section 6 describes related standards work and research in this area, whilst Section 7 noAssertion EXTENSION ::= { describes further standardization work that SYNTAX NULL is still needed to be done in the X.509 PMI IDENTIFIED BY { id-ce- framework. noAssertion } } 2. No Assertion of Privileges where id-ce-noAssertion is an object There are two scenarios where privilege identifier (OID) assigned in X.509. holders may be given privileges in an AC1, in order to delegate them to other entities, If present, this extension indicates that the but where they are not allowed to assert the AC holder cannot assert the privileges privileges themselves. The first is where a indicated in the attributes of the AC. This manager is tasked with allocating roles or field can only be inserted into AA ACs, and duties to subordinates, but is not allowed to not into end entity ACs. If present, this assert the roles or duties himself. The extension shall always be marked critical. previous section gave a couple of examples of this scenario, in the shape of an airline 3. X.509 Extensions to Support manager and a hospital manager. This the Delegation Issuing Service scenario is represented by Alice in Figure As described in the Introduction, three 1A. The second scenario is where a deployment models have been identified for delegation issuing service (DIS) is given a the DIS, two in [2], in which the DIS is set of privileges to delegate, as directed by issued with its own AC and we have termed the SoA. This is represented by the the AC PKI and PMI modes, and one from Delegation Issuing Service in Figure 1B. our own research, termed the PKI mode, in which the DIS does not have its own AC. We can prevent the holder of these privileges (Alice in Figure 1A and the DIS 3.1 DIS Empowerment in Figure 1B) from asserting them by The Delegation Issuing Service (DIS) needs placing a “no assertion” extension into the to be empowered by the SoA to issue ACs AC issued to it. This extension will inform on behalf of other AAs. This is done by all relying parties that understand the including an “indirect issuer” extension in extension that the AC holder is not allowed either the PKC or the AC issued to the DIS to assert the privileges contained within the by the CA or SoA respectively. The indirect AC. This extension obviously needs to be a issuer extension serves a similar purpose as critical extension, since any relying party the indirect CRL boolean of the issuing that does not understand it, must refuse to distribution point extension in PKI CRLs i.e. accept the AC, rather than simply ignore the it gives authority to the DIS. The indirect extension and allow the privileges to be issuer extension is formally defined in asserted. ASN.1 as: The “no assertion” extension is formally indirectIssuer EXTENSION ::= { defined in ASN.1 [6] as: SYNTAX NULL IDENTIFIED BY id-ce- 1 We do not consider it sensible to issue privileges to indirectIssuer } AAs via the subjectDirectoryAttributes extension of public key certificates, since the AAs would not be where id-ce-indirectIssuer is an OID allowed to delegate these privileges further by issuing assigned in X.509. additional PKCs, since they are not a CA. The indirect issuer extension may be used policy to request the AC to be issued, the by the relying party when validating an AC DIS will issue an AC on behalf of the chain to check that the AC issuer was requesting AA. Thus we need an extension empowered to issue ACs on behalf of other to be inserted into the AC, informing all AAs (otherwise anyone with a signing key relying parties that this certificate was issued could issue an AC and say it was authorized on behalf of a particular AA. This leads to by an AA). Alternatively, it may be used by the requirement for the “issued on behalf of” the DIS software at initialization time to extension, which is formally defined in check that it is empowered to act as a DIS. ASN.1 below. The draft extension to X.509 states that the issuedOnBehalfOf EXTENSION ::= { indirect issuer extension may be placed in SYNTAX GeneralName either an AC or PKC containing the IDENTIFIED BY id-ce- subjectDirectoryAttributes extension issued issuedOnBehalfOf } to a DIS by an SoA. In our research we have identified that this extension may also be where id-ce-issuedOnBehalfOf is an OID placed in a PKC that does not contain the assigned in X.509. subjectDirectoryAttributes extension. This extension is inserted into an AC by an The presence of this extension means that indirect issuer. It indicates the AA that has the subject AA (the DIS) is authorized by requested the indirect issuer to issue the AC, the SoA to act as a proxy and issue ACs that and allows the delegation of authority chain delegate privileges, on behalf of other to be constructed and validated by the delegators. This extension is always non- relying party if necessary (see section 4). critical, since it does not matter to a relying party if it understands this extension or not The GeneralName is the name of the AA when the DIS is acting as a privilege asserter who has asked the issuer to issue this AC by presenting this to the RP to assert the privileges contained within this certificate. The issuer of this AC must have been This extension can be used by a RP when granted the privilege to issue ACs on behalf validating an AC chain which has the DIS of other AAs by an SOA, through the acting on behalf of another AA somewhere indirectIssuer extension in its AC or PKC. in the AC chain (see section 4). This extension may be critical or non-critical 3.2 Requesting an AC as necessary to ensure delegation path When an AA wishes to delegate some of its validation (see next section). privileges to a subordinate, and wishes to use the services of a DIS to issue the AC on 4. Validating Indirect AC chains its behalf, it needs to contact the DIS to The X.509 standard already provides a request the certificate to be issued. How this procedure for validating privilege paths and communication is achieved is outside the delegation chains in the standard delegation scope of X.509. Some discussion of this is of authority scenario. This chain is provided later. Assuming this represented by the curved arrows that point communication is successful, i.e. that the to issuers in Figure 1A. This procedure AA is authenticated to the DIS, and is needs to be enhanced when indirectly issued allowed by the DIS’s attribute allocation ACs are encountered in the delegation chain, such as those in Figure 1B. As can be seen In PKI mode, the DIS does not have an AC, from the addition of the issuedOnBehalfOf but only has a PKC containing the arrows in Figure 1B, the procedure is more indirectIssuer extension. In this case the complex and more delegation links need to ACs issued by the DIS have to have the be validated when this extension is marked issuedOnBehalfOf extension set to critical, critical. since the DIS is incapable of performing any validation of the requesting AA other than Three deployment models have been authenticating that it is who it says it is. All identified, which we have termed the AC PMI validation has to be done by the RP. PKI, PMI and PKI modes. In PMI mode, the But this is in fact little different to the DIS has been issued with an AC by the validation performed in the AC PKI mode, SOA, which contains a superset of the and is if anything slightly simpler since the attributes that it will issue on behalf of other DIS only has a PKC to be validated and not AAs. This model presents the simplest path a PKC and an AC. validation processing, since the AC chains will always comprise of just two ACs: the In addition to the standard procedural tasks end entity’s AC signed by the DIS, and the of validating signatures and revocation lists, DIS’s AC signed by the SOA. The existing the relying party will also have to perform standard path validation procedure will work the following additional steps. for this AC chain. The RP may safely ignore the issuedOnBehalfOf and indirectIssuer i) Starting with the end entity’s AC, the extensions which will be marked as non- RP will need to extract the issuer critical, since the DIS had full authority to name and look at the critical flag of issue the ACs to the end entities even though the issuedOnBehalfOf name. in reality it was a peer AA that asked for the ii) If the issuedOnBehalfOf extension is delegation to be performed. Note that the marked critical, the RP retrieves the DIS might not have permission to assert ACs of the issuedOnBehalfOf AA these privileges itself, but that will be and validates that the AA has a signaled separately by the noAssertion superset of the privilege attributes extension. issued to the end entity and that the ACs have not been revoked. If it In AC PKI mode, the DIS has an AC does not have sufficient privileges, containing the indirectIssuer extension, but or they have been revoked, the end does not have any of the attributes that it entity’s AC is rejected. The RP will issue to others. These are held by the retrieves the certificates (ACs and AAs that request the DIS to issue the ACs. PKCs) of the issuer and validates In this case the issuedOnBehalfOf extension that the issuer is an indirect issuer of must be set to critical, since the RP will need the SoA (i.e. has the indirectIssuer to validate that the requesting AA had extension in one of its certificates). If sufficient privileges to delegate to the end not the end entity’s AC is rejected. entity. If the extension was not set to critical, iii) If the issuedOnBehalfOf extension is the RP is likely to compute that the AC missing or non-critical, the RP chain is invalid since the DIS issuer did not retrieves the ACs of the AA (the have a superset of the privileges that were DIS) and validates that the AA has a allocated to the end entity. superset of the privileges issued to the end entity. If not, the end entity’s AC is rejected. nothing to stop this from happening. For this iv) For each AC of the issuer that reason, SPKI decided (in section 4.2 of [11]) contains one or more of the that they were powerless to stop this in their delegated privileges, the RP recurses simple certificates that tied authorizations to to step i) for each AC, thereby public keys. However, X.509 has the moving up the delegation chain. This advantage that AAs are given globally recursion continues until the RP unique names by CAs. Providing an AA is arrives at the AC of an AA that is not able to obtain an alias name for itself issued by the trusted SoA(s) who from the same or another trusted CA then is(are) the root(s) of the PMI. This the relying party can check if any AA’s AC validates that the privileges were in a certificate path has the noAssertion properly delegated. extension set, and if it does, apply it also to any subordinate ACs that contain the same 4.1 Validating the noAssertion holder name. Clearly if an AA is able to extension obtain totally unrelated aliases from one or If an AA’s certificate has the noAssertion more trusted CAs, then the RP is unlikely to extension in it, what is to stop the AA know that the AA is asserting privileges that issuing another AC to itself and omitting the it was not intended to, by using an alias noAssertion extension? Clearly there is name. 1 ACM ACM DIS Single Java program 2 Web Service Interface Web DIS Web Service browser SSL or 4 Shibboleth DIS SSL or Web Service 3 Shibboleth Interface Apache DIS Apache Figure 2. DIS Communications implementing dynamic delegation of 5. Implementing the DIS authority. However, a number of issues We decided to implement the DIS as part of needed to be resolved that are not addressed the PERMIS X.509 PMI, as an aid to in the proposed extensions to X.509. Firstly there is no mention of how the limit AC path lengths to two, and if the communication between the DIS and the AA target policy is willing to trust the DIS as a should be achieved. Clearly the use of a root (as well as the SoA) then path standardized protocol is preferable to a validation lengths are reduced to just one proprietary one. One can envisage that an AC, that of the end user. IETF working group such as PKIX might define a protocol similar to CMP [3], using a In our implementation, the DIS is given an request similar to a PKCS#10 message [4]. AC containing a full set of privileges, and is In the absence of such a standard, in our configured with its own PERMIS PDP. The own research we are proposing to use a Web PDP is configured with an attribute (or role) Services protocol (see d in Figure 2), and assignment policy (RAP) [7], so that it can the Java GSSAPI [19] for authenticating the validate the AA requests. At initialization user. The GSS tokens will then be base64 time the DIS will check that its AC has the encoded and inserted into SOAP messages. indirectIssuer extension in it, otherwise it We are also defining a Java API for the DIS will fail to start. When an AA asks for an (see c in Figure 2), so that the DIS can be AC to be issued, the DIS will check that the built into other Java programs such as the AA is allowed to do this under the RAP PERMIS Attribute Certificate Manager policy, and also that the set of attributes (ACM) and called directly by it. In this case requested are a subset of those held by the user authentication is not necessary. We are DIS. Validation against the RAP is done by also proposing to adopt a 3 tiered model the existing PERMIS PDP code. It is passed where an Apache server acts as the DIS the (unsigned) AC requested by the AA, and client, authenticates the AAs via either it validates the credentials in the AC against Apache authentication (e.g. SSL) or the RAP. The only modification needed to Shibboleth (see f in Figure 2), and then PERMIS is to provide it with a null acts as a proxy for them to the DIS. It would signature validation object that will return also be possible for Apache to directly call signature valid to every request to validate the DIS via our Java API (see e in Figure the unsigned ACs. If the AC passes the 2). policy, the DIS will check that the requested attributes are a subset of those it holds in its Secondly there are a number of issues own AC. The task of the RP is now made concerned with AC path validation. As much simpler, since it only needs to validate pointed out by Knight and Grandy in [18] 1 or 2 ACs, that of the user issued by the this can be extremely complex when DIS, and optionally that of the DIS issued dynamic delegation of authority is by the SOA. implemented. We want to simplify this process as much as possible. We have Finally we wanted to simplify the use of already taken the step of not issuing role PMIs in organizations that do not have fully specification ACs, and instead we store their functional PKIs implemented. These contents in each target’s PERMIS policy organizations, which are in the majority, read in by its PDP at initialization time. We already have a fully functional user thus only issue role allocation ACs. Our authentication mechanism, and only have a preferred DIS deployment model is the PMI handful of PKCs, e.g. web server mode, since the DIS is issued with a role certificates. It is for this reason that we have allocation AC containing a superset of the chosen to implement communications attributes that it can delegate. In this way we between the user and DIS as a three tiered model via an Apache web server as in path is provided with the PAC and the f in Figure 2. This will allow organizations appropriate CV (sent confidentially, of to use their existing authentication method. course). The delegate then presents the PAC One problem that has to be solved is that of to the target along with the CV. The target proxying, since the DIS will authenticate validates that the hash of the CV Apache, Apache will authenticate the user corresponds to a PV in the PAC, and if so and Apache will then ask for an AC to be allows the delegate to have the appropriate issued on behalf of the user. The DIS has to delegated access on behalf of the user. know if Apache is authorized to proxy in Different delegates can be given different this way. We could solve this in a couple of CVs which authorize different subsets of the ways. We could configure the details (name privileges contained in the PAC to different address of Apache) into the DIS. Or we sets of target resources. The EC SESAME could issue Apache with its own AC project [8] implemented a subset of ECMA containing a proxy privilege. When Apache Standard 219 and this was eventually rolled authenticates to the DIS, the DIS will call out into several commercial products from the PERMIS PDP to validate Apache’s AC, the project’s partners. The disadvantage of and if it has the proxy credential the DIS the ECMA scheme is that the user has to will allow it to request ACs be issued on know in advance of requesting the PAC behalf of other AAs. what delegation is required, since this is built into the PAC at the time of its issuance. 6. Related Research Some of the earliest standardization work ECMA Standard 219 supports both for attribute certificates and attribute symmetric and asymmetric encryption for certificate issuing servers was undertaken by protection of the PACs, since it supports ECMA in the late 80’s and early 90’s. This both Kerberos V5 [10] and digital signatures lead to the publication of ECMA Standard for user authentication to the authentication 219 [9] which specifies a model for server prior to contacting the PA-Server. distributed authentication and access Interestingly, X.509 decided to standardize control. The Privilege Attribute Certificates on only asymmetric encryption for its (PACs) described therein are a forerunner of certificates, whereas Microsoft Windows the attribute certificates later standardized in decided to adopt Kerberos and symmetric X.509. A Privilege Attribute Server (PA- encryption for its tokens when allowing Server) is responsible for issuing PACs to users to gain access to multiple Windows users, and is similar in concept to the DIS services. described in this paper. However, to support delegation of authority between principals, The Simple Public Key Infrastructure new PACs are not issued to the delegatees (SPKI) [11] IETF working group, whose (as in this paper) but rather the PA-Server work eventually merged with the Simple provides the initial user with a PAC that Distributed Security Infrastructure (SDSI) contains one of more embedded Protection [12] of Ron Rivest, defined three types of Values (PVs) that can be used for certificate which mapped names, subsequent delegation. A PV is a hash of a authorizations and group names respectively secret Control Value (CV). The user is to public keys. Authorization certificates can separately issued with the corresponding be further delegated, and this is indicated by CVs. When a user wishes to delegate a Boolean flag set by the issuing delegator. authority to another user or server, the latter The delegator can set the Boolean as desired, except that if the Boolean is already can also carry information about which false in the authorization certificate privileges are being delegated, i.e. none, all delegated to him/her then it cannot be or a subset, the latter being defined in an switched back to true and be trusted. It application specific way. Grid applications therefore would be easy to apply the DIS and users could use the DIS framework concept and service to SPKI using the PMI described here as an alternative to the latter, mode deployment model, i.e. where the DIS and ask the DIS to issue ACs to their grid is delegated an authorization certificate with jobs that contain a subset of the privileges the Boolean set to true. However it would contained in the user’s AC. We plan to break the theory of SPKI to implement demonstrate this feature in due course, since either of the two PKI mode deployment PERMIS is already integrated with Globus models since these require the toolkit [14]. issuedOnBehalfOf extension to be present in the delegatee’s certificate, and this would More recently the work on Shibboleth [15] mean that the certificates are no longer has implemented a limited mechanism for simple according to SPKI’s definition. delegation of authority. In this case a target site delegates to the user’s home site the task One feature included in SPKI that is not of authenticating and assigning attributes to formally in the X.509 standard, is a rights the user. The user’s privileges are returned language for expressing authorization to the target site in the form of a SAML policies. Consequently PERMIS defined its Attribute Statement [16] signed by the home own policy language, written in XML [7]. site. In research described in another paper SPKI uses S-expressions. X.509 has left it to at this conference [17], we have extended other standards, e.g. the ISO Rights the Shibboleth delegation model by Expression Language [20] to specify the integrating it with PERMIS and X.509 ACs. policies. This means that the policy rules by The DIS will then be able to be used by which a DIS operates are not specified in home sites to delegate privileges even X.509. further. Proxy certificates, defined initially by the 7. Further Work Globus grid software developers, and later As indicated above, a protocol for published as an IETF proposed standard interactions between an AA and a DIS will [13], use a different model for delegation of need to be standardized so that requests to authority. In this model a user, who is the issue ACs can be made in a standard subject of a public key certificate (and manner. This request-response protocol may defined as an end entity by the X.509 be similar to the PKIX CMP protocol, but it standard), issues his own PKC (called a need not be, since proof of possession of the proxy certificate) to the public key of his private key is not essential (indeed one of grid job which has previously generated its the motivations for having a DIS is that the own key pair. Validating the proxy users may not have their own key pairs). In certificate of course breaks the standard many scenarios AAs may not be PKI users, X.509 certificate path validation rules, since but rather may use Kerberos, biometrics or an end entity is not allowed to act as a CA. symmetric tokens for authentication. In this To rectify this, a critical extension case the AAs are computationally unable to (proxyCertInfo) is added to the proxy issue X.509 ACs so will need to use the certificate to indicate the fact. The extension services of a DIS to issue the ACs on their behalf. But they will be unable to sign those and made some constructive comments that requests to the DIS. In this case a web helped to improve it. services interface like the one we propose to use may be more appropriate, with the AA References using a web browser to interact with the DIS [1] ISO 9594-8/ITU-T Rec. X.509 (2000) via a web server, and perhaps authenticating The Directory: Public-key and attribute with a username and password over an SSL certificate frameworks link. Whatever protocol is standardized, it [2] ISO SC 6 N12596 “Proposed Draft will need to be flexible enough to cater for Amendment on Enhancements to Public- the different environments in which it may Key and Attribute Certificates”, Geneva be used. output, March 2004 [3] C. Adams, S. Farrell. “Internet X.509 Practical experience of working with X.509 Public Key Infrastructure Certificate PMIs is only just beginning. Most Management Protocols”. RFC 2510, March organizations who are experimenting with 1999 PMIs use them internally initially. They [4] Kaliski, B., "PKCS #10: Certificate define their own privilege attributes and Request Syntax, Version 1.5." RFC 2314, therefore the relying parties and SoAs have March 1998. a common understanding of both the [5] D.W.Chadwick, A. Otenko, E.Ball. semantics and syntax of these privilege “Role-based access control with X.509 attributes. However, as organizations move attribute certificates”, IEEE Internet towards role based or attribute based access Computing, March-April 2003, pp. 62-69. controls, and federations between [6] ITU-T Recommendation X.680 (1997) | organizations, including the formation of ISO/IEC 8824-1:1998, Information virtual organizations, they will find that the Technology - Abstract Syntax Notation One attributes and roles they have defined are (ASN.1): Specification of Basic Notation different from those in use by their [7] D.W.Chadwick, A. Otenko. “RBAC federation partners. When this starts to Policies in XML for X.509 Based Privilege occur, organizations will not want to re- Management” in Security in the Information issue ACs to users from the federated Society: Visions and Perspectives: IFIP organizations, but rather will wish to TC11 17th Int. Conf. On Information understand and use the ACs that have Security (SEC2002), May 7-9, 2002, Cairo, already been issued. This will require cross Egypt. Ed. by M. A. Ghonaimy, M. T. El- certification between PMIs, the mapping of Hadidi, H.K.Aslan, Kluwer Academic role allocation policies between Publishers, pp 39-53. organizations and constraints on what [8] T.Parker, D.Pinkas. “Sesame V4 foreign users may asserts in home domains. Overview”, Issue 1, Dec 1995. Available It is anticipated that this work will form the from bulk of the standardization activity for the https://www.cosic.esat.kuleuven.ac.be/sesa sixth edition of X.509. me/html/sesame_documents.html [9] Standard ECMA-219 "Authentication Acknowledgements and Privilege Attribute Security Application The authors would like to thank the UK with Related Key Distribution Functions" JISC for funding this work under the Parts 1, 2 and 3, December 1994. DyVOSE project, and the NIST PC [10] J. Kohl, C. Neuman. “The Kerberos members who robustly reviewed this paper Network Authentication Service (V5).” RFC 1510, Sept 1993. (MPEG 21) — Part 5: Rights Expression [11] C. Ellison, B. Frantz, B. Lampson, R. Language [REL]”. 2004 Rivest, B. Thomas, T. Ylonen. “SPKI Certificate Theory”. RFC 2693, Sept 1999. [12] Ron Rivest and Butler Lampson, "SDSI - A Simple Distributed Security Infrastructure [SDSI]", See . [13] S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. “Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile”. RFC3820, June 2004. [14] David W Chadwick, Sassa Otenko, Von Welch. “Using SAML to link the GLOBUS toolkit to the PERMIS authorisation infrastructure”. Proceedings of Eighth Annual IFIP TC-6 TC-11 Conference on Communications and Multimedia Security, Windermere, UK, 15-18 September 2004 [15] Scot Cantor. “Shibboleth Architecture, Protocols and Profiles, Working Draft 02, 22 September 2004, see http://shibboleth.internet2.edu/ [16] OASIS. “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) v1.1”. 2 September 2003. See http://www.oasis- open.org/committees/security/ [17] David Chadwick, Sassa Otenko, Wensheng Xu. “Adding Distributed Trust Management to Shibboleth” presented at NIST 4th Annual PKI Workshop, Gaithersberg, USA, April 19-21 2005 [18] Knight, S., Grandy, C. “Scalability Issues in PMI Delegation”. Pre-Proceedings of the First Annual PKI Workshop, Gaithersburg, USA, April 2002, pp67-77 [19] Charlie Lai, Seema Malkani. “Implementing Security using JAAS and Java GSS API” Presentation from 2003 Sun JavaOne conference. See http://java.sun.com/security/javaone/2003/2 236-JAASJGSS.pdf [20] ISO/IEC 21000-5:2004, “Information technology — Multimedia framework Delegation Issuing Service for X.509 David Chadwick University of Kent NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 1 Contents • Delegation of Authority in Organisations • X.509 Delegation Model (2001 edition) • New Delegation Service Model (2005 edition) • Implementing the DIS in PERMIS • Comparison with other models • Further standardisation work still needed NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 2 Assigning and Delegating Privileges in Organisations “I authorise this Privilege Holder to use Resource this resource in the following ways” Owner signed The Resource Owner Assigns privilege “I delegate authority to this End User to use this resource in this limited way” Privilege signed The Privilege Holder Holder End User (Privilege Delegates privilege Holder) NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 3 Privilege Checking in Organisations End User (Privilege Holder) “Please purchase this Issues a product from company X” command signed the End User (Asserts Privilege) Q. “Is this user authorised Privilege Verifier to purchase these goods?” NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 4 X.509 PMI Entities Source of Authority (SoA) Assigns privilege Trusts Asserts privilege Attribute Authority (AA) (optional) Privilege Verifier Delegate privilege Asserts privilege Privilege Holder (End Entity) NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 5 Assigning Privileges in X.509 (2001) Points to issuer SOA Bill AC Issues AC to Points to holder AA Alice Issues AC to End Bob Entity NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 6 Verifying Privilege in X.509 Privilege policy Environmental variables Directory Certificates and CRLs (pull) Privilege Verifier Resource being Certificates (PEP/PDP) protected and CRLs (push) (object) Service Request Privilege Asserter(object method) NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 7 Deficiencies in X.509 (2001) Model • No way to flag that an AA cannot assert the privileges in the ACs it holds • No way to allow a manager who does not have a PKI key pair to delegate authority • Can be difficult to collect audit information if ability to issue ACs is fully distributed. • Can be inefficient to enforce delegation policy by adding lots of extensions to the ACs e.g. – Delegated Name Constraints, Basic Attribute Constraints, Acceptable Certificate Policies – Central control vs. distributed control • Most of these can be solved by introducing a Delegation Service NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 8 The X.509 Delegation Service Points to AC holder SOA Bill Issues Points to issuer Points to Issued On AC to Behalf Of Issues AC to AA Alice Delegation Issues Issuing AC to Service (DIS) End Entity Bob NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 9 Advantages of Introducing a DIS • DIS can support a fully secure audit trail (just like a CA) • DIS can enforce corporate assignment and delegation policy efficiently • Managers do not need to be PKC enabled in order to delegate authority. DIS can support multiple authentication methods • DIS can improve performance of AC chain validation if it is given the privileges – Shortens the AC chain length to 2 (SoA → DIS’s AC → end entity’s AC) – Reduces the number of ACRLs that need to be published • When a manager’s AC is revoked or expires, we do not necessarily need to revoke all the end entity ACs, because they still may validate successfully (i.e. when DIS is operating in PMI mode) NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 10 DIS Deployment Models • AC PKI mode – DIS issues ACs on behalf of managers but does not hold the privileges itself in its AC. Instead, its AC only contains the indirectIssuer extension (similar to indirect CRLs) • PKI mode – DIS issues ACs on behalf of managers but does not have an AC itself. Instead its PKC contains indirectIssuer extension. • PMI mode – DIS has its own AC, issued by SoA, with superset of all privileges it will delegate to others on behalf of managers. AC contains the noAssertion extension. NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 11 Disadvantages of a DIS • In AC PKI and PKI modes, the validation of the AC chain is more complex (see later) • In PMI mode, on cross certification between PMIs, a DIS has to be cross certified rather than individual AAs, so there is some loss of granularity • If all revocations are issued by the DIS, then ACRL could get very large (without distribution points) • DIS’s AC signing key is online so that it can be used dynamically to generate ACs. Can be unacceptable security weakness in some deployments NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 12 X.509 Support for DIS • noAssertion extension, says that AC holder cannot assert the attributes in the AC • indirectIssuer extension, says the cert holder is authorised to issues ACs on behalf of other AAs • issuedOnBehalfOf extension, says which AA requested this AC to be issued NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 13 No Assertion Extension • Prevents an AA (such as a DIS) from asserting the privileges it can delegate noAssertion EXTENSION ::= { SYNTAX NULL IDENTIFIED BY { id-ce-noAssertion } } • Always critical, and only in AA ACs • What is to stop an AA issuing an AC to itself and omitting this extension? – SPKI determined nothing, so cannot support this – In X.509 all AAs have globally unique names. So if an AA cannot get an alias name from a trusted CA then PV can check all ACs issued to this AA. NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 14 Indirect Issuer Extension • Needed in PKI and AC PKI modes to tell Privilege Verifier that the AA is authorised to issue ACs on behalf of other AAs – otherwise I could issue an AC and say that it was Tony Blair who requested it ☺ • Not needed in PMI mode since DIS holds all the privileges it is delegating indirectIssuer EXTENSION ::= { SYNTAX NULL IDENTIFIED BY id-ce-indirectIssuer } • Always set to non-critical NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 15 Issued On Behalf Of Extension • Needed in PKI and AC PKI modes to validate certificate chains, so set to critical • Can be used in PMI mode for audit purposes, so set to non-critical issuedOnBehalfOf EXTENSION ::= { SYNTAX GeneralName IDENTIFIED BY id-ce-issuedOnBehalfOf } NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 16 Verifying Claimed Privileges • In PMI mode, existing standard procedure used – Chain of ACs is checked, issuer to holder back to trusted SoA. Attributes are checked for subsetting. • In PKI and AC PKI modes, issuedOnBehalfOf extension is marked critical – Check AC of AA in issuedOnBehalfOf, that it has a superset of the privileges in this AC. If not, reject – Check that PKC or AC of issuer has indirectIssuer extension set. If not reject. – For each AC of the issuer that contains one or more of the delegated privileges, recurse up the chain – Stop when you get to ACs issued by trusted SoAs NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 17 Implementing the DIS • Issues to be addressed • Communications between AA and DIS – Several modes are envisaged, from Java API to web service interface • Validating that AA is authorised to request a particular AC for a user – We can use the existing PERMIS PDP and Role Allocating Policy for this • Minimising the PDP’s processing time to reach a decision – We use the DIS PMI mode of operation – If DIS is made a root of trust then AC chain length is always one NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 18 1 DIS ACM ACM Java Single Java program 2 Web Service Interface Web DIS Web Service browser SSL or 4 DIS Shibboleth Java SSL or Web Service 3 Shibboleth Interface Apache ACM=Attribute DIS Certificate Manager Java Apache DIS Communications NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 19 PERMIS Attribute Certificate Manager NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 20 3 Tiered Model Shibboleth SSO SAML DIS responses Web Web forms Service SAML requests over Https Https Get Post etc Apache Server (DIS Client) Manager (AA) NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 21 Pilot Web Browser Interface NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 22 DIS Web Service Authenticate Map DIS Client identities Authn name Authzn name GetCreds GSS API ? IssueAC PERMIS RBAC DIS Web DIS Java Decision service Object Web service interface publishAC (optional) Sign Publish NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 23 Comparison of DIS with other • ECMA 219 Delegation Models – Has PACs and PAS. PAS is similar to DIS, but delegation is not supported through new PACs but rather through embedding Protection Values in original PAC. PV is hash of a secret Control Value. PAC holder gives PAC and secret CV to the delegate • SPKI – Authorisation certs similar to X.509 ACs. In SPKI delegation is flagged via a boolean, in X.509 as an integer signifying allowed depth. DIS in PMI mode can easily be applied to SPKI • Grid Proxy Certs (RFC 3820) – A PKC is issued to delegate by manager, and carries an indication of which rights are assigned to delegate • Shibboleth – Delegates authorisation and attribute assignment to a user’s home site NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 24 Standards Work Still Needed • AA info access – to say how/where to obtain the AC of the AA issuing this AC (similar to PKC AIA) • Protocol to request an AC to be issued – Similar to PKCS#10 or CMP • Web services protocol for accessing a DIS • Cross certification between SoAs NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 25 Any Questions • ?????????????????????????????????? ?????????????????????????????????? ?????????????????????????????????? ?????????????????????????????????? NIST PKI Workshop 19 April 2005 © 2005 David Chadwick 26 Meeting the Challenges of Canada’s Secure Delivery of E-Government Services Mike Just Danielle Rosmarin Public Works and Government Services Canada {mike.just, danielle.rosmarin}@pwgsc.gc.ca Abstract including interjurisdictional considerations, We describe a number of technical, legal, business registration, citizen enrolment, and policy and business issues related to the evidentiary support for electronic data. In development and deployment of Canada’s effect, we argue that tackling these issues is PKI-based solution for authenticating critical in order for Canada’s PKI-based individuals and businesses. We argue that secure e-government service delivery to be tackling these issues is critical in order for truly transformative. Even though other Canada’s PKI-based solution to truly jurisdictions’ legislative and policy transform Canada’s e-government services frameworks may differ from Canada’s, the delivery, and we offer insights into options spirit will likely be similar so that other that could resolve outstanding and jurisdictions and solution builders should remaining issues with this solution. gain some valuable information from our experience. 1 Introduction Beginning in 1999, the Canadian 2 Background Government initiated the Government On- Before we discuss the current issues related Line (GOL) project, which included the to secure service delivery, we review the development of an online presence for legislative and policy regime within Canada, approximately 130 of the most frequently and the technical solution supporting a used government services. The project also secure e-government service delivery, the included the provision of authentication Secure Channel (SC) infrastructure. services as part of the “Secure Channel” infrastructure, using public key credentials, 2.1 Legislative and Policy giving departmental programs the means for Instruments properly identifying and controlling access Politically, Canada is a federation in which to individuals’ personal information. Since the federal government is composed of the initial goals for the GOL project have approximately 130 departments and been accomplished, it is time to look to the agencies. There are 10 provinces and 3 future as more services move online, and territories, each with their own departments more complicated transactions are and agencies. Numerous legislative and supported. policy instruments govern their behaviour. In the federal government, each department While technology issues and decisions were mandate is captured in legislation. We will paramount in the early years for GOL, many briefly describe the legislation and policy of today’s issues reflect legal, policy and instruments that are most relevant to this business concerns. The technology solutions paper. are typically available or at least achievable; what remains is the deployment so as to best Public Works and Government Services meet these other concerns. In this paper, we Canada (PWGSC) delivers the SC identify several current issues related to the infrastructure supporting the secure delivery secure delivery of services to Canadians, of services, and is governed by the Department of Public Works and enterprise communication environment for Government Services Act [DPW86]. This the federal government, the SC’s act stipulates that PWGSC is a common authentication services support the service agency for the Government of identification of citizens and businesses Canada (GoC), providing the GoC’s (hereafter referred to generically as departments, boards and agencies with individuals). We expand upon these services in support of their programs. The authentication services below (see also Just Privacy Act [PA85] extends Canada’s laws [Just03] for further information). that protect the privacy of individuals with respect to the collection, use, and disclosure In order to authenticate themselves prior to of personal information about themselves accessing certain online government held by a federal government institution. services, individuals can obtain an epass, an The Personal Information Protection and online credential issued by the Government Electronic Documents Act (PIPEDA) of Canada (GoC). An epass consists of a [PIPE00] establishes similar rules and while private/public key pair and associated public the Privacy Act, applies only to GoC key certificate. The certificate is indexed by departments and agencies, PIPEDA also a Meaningless But Unique Number applies to provincial governments and the (MBUN) that has no association with the private sector. individual’s identity. On its own, this certificate is anonymous; until which time Notable policies (applying only to the an individual enrols with a government federal government) that affect the delivery program and the MBUN is associated with of e-government services include: the existing government program identifiers Government Security Policy [GSP02], which (such as an individual’s Social Insurance safeguards employees and assets and assures Number – SIN, which is roughly equivalent the continued delivery of services; and the to the US Social Security Number) for the Privacy Impact Assessment Policy [PIA02], individual (at which point the certificate is which prescribes Privacy Impact pseudonymous). Assessments when there are proposals for, and during the design and implementation of The process of establishing this secure programs and services that raise privacy relationship between the individual’s issues. Additionally, the Common Services MBUN and a government program for Policy [CSP] is designed to ensure that online service delivery is composed of the departments and agencies can acquire following steps: responsive, cost-effective support for their • The individual registers in order to program delivery, while the Common Look obtain their epass. No identification is and Feel Standard [CLF00] is designed to required by the individual at this stage. ensure that all Canadians, regardless of • The individual enrols with a government ability, official language, geographic program, involving (where required) location or demographic category, are given o The identification of the equal access to information on GoC web individual to the program (based sites. on shared, secret information between the individual and the 2.2 Canada’s Secure Channel program), Canada’s Secure Channel (SC) is a o The mapping of the MBUN from collection of network infrastructure, the epass certificate to the operations, and security and authentication existing Program Identifier (PID) services supporting the Government On- that identifies the individual Line (GOL) project. While the Secure within the government program. Channel Network (SCNet) supports a secure This mapping is thereafter retained at the program. Upon subsequent authentication to the organizations that have encountered, or government program, the MBUN from the expect to encounter, similar situations. individual’s certificate is mapped to the PID, thereby identifying the individual, and the 3.1 Guiding Principles/Goals resources they can access. In addition to the In delivering government services, there are epass registration, management operations three entities to consider, and hence three such as self-revocation and recovery are also different perspectives from which to judge supported. the quality of service delivery: the individual user, the department and the enterprise (as Since 2002, over 285,000 epasses have been representative of the whole-of-government). issued to individuals. Key epass-enabled The user perspective is to have their access applications include Change of Address with to services unencumbered by technology or the Canada Revenue Agency and filing politics. Therefore, the “user experience” is Records of Employment with Human important. In addition, users are concerned Resources and Skills Development Canada. with ensuring both the security of their information (and their person!) and well as The SC’s authentication services advantage their privacy. Departments are similarly is that beyond offering a solution that concerned with the needs of their users, but supports the protection of individuals’ also want to offer the most effective and privacy, it provides a common solution for efficient solution possible. Cost is always an use by all departments, avoiding the important concern so that re-usable solutions arguably less efficient “siloed solutions” that offer an important advantage to departments. might be built by each department. It is the enterprise perspective in which the needs for the whole-of-government are In further support of privacy, individuals are considered. Effectiveness and efficiency able to obtain one or more epasses (e.g. across all of government is recognized, mapping to a number of different without the sometimes-narrower constraints government programs). It is likely though of departmental budgets or other that individuals will opt for a manageable requirements. Within the Canadian number of epasses, supporting a more government, the enterprise perspective is consistent experience in their authentication upheld by designated central agencies (that to government. Note also that no personal develop government policy) and common information about an individual is service organizations, such as PWGSC, that maintained centrally to support the epass implement common solutions (including the service; personal information about a user is Secure Channel) within the government’s retained within the context of their policy framework. relationship within a program. Throughout the evolution of Secure Channel, there are a number of challenges 3 Meeting the Challenges have arisen from attempting to satisfy these Related to Secure Service perspectives within our legal, policy and business constraints. In the following Delivery subsections we overview a number of these As Canada continues to offer secure online challenges. services to citizens and businesses, a number of issues have been overcome, while some 3.2 Inter-Jurisdictional Issues remain. This section reviews some of our As mentioned earlier, a number of successes, and considers how we might jurisdictions exist within Canada, each with address a number of lingering challenges. It their own legislative and policy framework, is anticipated that this overview will aid and with their own business requirements. Despite these differences, each jurisdiction through another common service or level of government (federal, provincial, organization, or even choosing to reject the and municipal), interacts with the same set idea of an improved government experience of individuals: Canadian citizens and across multiple levels of government. businesses. For example, the federal However, one can also recognize that we are government is responsible for tax collection, now in an environment that may not have the provincial for access to health services been anticipated by legislation and for which and for issuing drivers licenses, while the it is reasonable to investigate legislative municipal is responsible for water and sewer alternatives. In Canada, this option can be services. In addition to public services, achieved through an Order-in-Council individuals also interact with, and obtain (OIC), involving approval by the Governor services from the private sector (e.g. banks). General, Canada’s head of state, and is currently being investigated. The Secure Channel solutions currently support the delivery of federal government Beyond current legislative hurdles, potential services. To support an improved user policy obstacles also exist. For example, in experience, it would be advantageous for the federal government (in support of services to be similarly offered across other consistent user experience), there exist jurisdictions. Of course, such integration of standards supporting a “Common Look and service offerings must be performed within Feel” for government online systems. These the constraints of legislation and policy, standards go so far as to specify the required especially with regard to privacy. presentation format for web pages. However, in a joint federal-provincial As an example, consider the use of a single presentation, provinces have similar, authentication infrastructure for citizens to sometimes conflicting, policies suited to access government services. As with the their own requirements. As the federal current epass solution for federal services, policies apply only to federal departments, users can choose to use one epass across all there is a gap with regards to policies across services, or use separate epasses for any all levels of government; the common look number of services. Although there might and feel standards are likely but one exist some obstacles to such an endeavour example. (e.g. technical, perception), one clear obstacle is found in current legislation. The Therefore, as we endeavour to offer systems common service organization that provides across multiple levels of government, we’ll the Secure Channel services is governed be sure to uncover other areas where a pan- legislatively by the Department of Public jurisdictional policy regime is lacking. Works and Government Services Act (see Section 2.1) In both this legislation and 3.3 Business Registration Issues other policy (for instance, the Common A business transacting with the Government Services Policy (see Section 2.1)), PWGSC of Canada (GoC) typically has a number of is recognized as a “common service government-issued identifiers for its organization” for the Government of dealings with the various departments and Canada, but the legislation limits this programs of the GoC. While the Business authority to offering services only to Number (BN)1, issued by the Canada “departments, boards and agencies.” Thus, Revenue Agency (CRA) to Canadian the Act currently prevents the offering of businesses for tax purposes seems to have services to our provincial counterparts, for the widest coverage, the use of the BN example. beyond tax purposes is currently limited by legislation. As a result, although many There are a number of options for dealing businesses have a government issued BN, with this issue, including offering solutions not all government departments can collect identifier, the solutions are for specific uses, and use the business number for rather than having a definitive identifier that identification purposes in their be consistently used for online transactions. programming. Thus, businesses obtain other Making the BN the sole common identifier identifiers for interacting with the GoC for for business and making its usage more non tax-purposes. This is important to note widespread would entail legislative change when considering that a common identifier either on the part of CRA or other could be used in a common registration departments and provincial jurisdictions. process for access to online government services. Having a single registration Alternatively, an altogether distinct number, number for a business’ transactions with the publicly available and created specifically to GoC would simplify and enhance a be a common identifier for businesses in business’ interactions with the GoC as a their dealings with the GoC, may resolve whole and further enable business-to- this issue. It is likely that legislation would government online transactions. have to be enacted to allow the creation, collection, use and disclosure of this new An ideal scenario for business registration is ubiquitous identifier. That said, it may be that there would be an efficient way of simpler to create a new number than persist identifying businesses once for their in using an identifier that requires legislative dealings with the GoC. Subsequent change to enable its expanded use within the authentication would be simple for both the GoC and in the provinces. Other benefits businesses and the GoC and would be used include that the public could view the for all business-to-government online business number and other businesses could transactions. One may also wonder if an rely on it to verify the legitimacy of other anonymous credential such as an epass entities. could be used for business registration purposes. And although epass meets This very scenario occurred in Australia in privacy requirements that are critical for 1999 when the A New Tax System individuals, the purpose of an identifier for a (Australian Business Number) Act 1999 business is precisely to identify from an came into force. The act created the authoritative source that a business is Australian Business Number (ABN)2, which legitimate. In addition, with businesses, is related to, but distinct from a businesses’ individual enrolments may not be necessary tax file number and is used when dealing as they are currently with citizens in order to with the Australian Tax Office, other maintain the information silos. government agencies, and when supplying Presently, CRA uses the BN to identify its goods and services to other businesses. business clients and departments including Industry Canada, PWGSC and Statistics The absence of a persistent identifier for Canada, and the provinces of British businesses dealing with the Government of Columbia, Manitoba, New Brunswick, Nova Canada hinders the seamless development of Scotia and Ontario are using the BN for online business-to-government transactions business identification in varying ways. because departments must individually These departments and provinces were able collect similar identifying information from to adopt the BN as a common identifier the same business when this information because they changed their legislation to could be collected once and then shared and allow the use of the BN for this purpose and re-used by other GoC departments. Having a signed memoranda of understanding with common identifier, supported by a central, CRA to use it. This business registration searchable business registry would solution only partially fulfils the need for a streamline the registration process for online single registration number, because even services, allow government departments to though the BN is used as a common leverage the work of others while presenting a single-window to business interacting with the GoC. While the issue of determining a The scenario described above allows the common identifier for online business programs offering the service to identify authentication with the GoC has not been individuals to the level of assurance it resolved, “catalytic projects” that are part of wishes to have and it also keeps the Canada’s GOL initiative are addressing information provided for enrolment in a elements of the problem. For instance, the program-specific silo. Registration for, and purpose of the Common Business maintenance of, the credential can be Authentication catalytic project is to centrally managed (as no personal implement a common authentication service information is collected) offering significant for businesses and individuals in dealing benefit. However, to the individual who may with government [SCF04]. Providing assume that GoC departments already share tombstone information once, the business this information, separate program would then be authenticated once for enrolments may lessen the quality of the multiple services and while having a view of individual’s experience. In other words, a all government transactions. pleasant, non-repetitive experience presupposes either a shared, central While the Canada Revenue Agency BN repository of information, or an information need not become the common identifier for exchange facility in which the individual businesses, it would be advantageous to could decide to share enrolment information make a publicly available business identifier across government programs. As it stands mandated by legislation for use by the entire now, an individual has to authenticate Government of Canada. As in Australia her/himself for each epass enabled services with its ABN, this business identifier would despite being able to register for only one then be the foundation for authenticating the epass. Due in part to legislative and business entity transacting with the GoC. political hurdles, there is no central Furthermore, it could also become an authentication facility for users and identifier used among businesses, and the departments cannot use another service’s public in verifying the legitimacy of a authentication for its own. In the following business entity. paragraphs, we examine the feasibility of two other options. 3.4 Citizen Enrolment Issues When a citizen chooses to use the GoC Joint Information Exchange Facility epass service to transact online with the The Joint Information Exchange Facility is a GoC, the individual registers for one or any concept that demonstrates how a user can number of epasses through a central choose to share authentication information service.3 But in order to access specific PKI- provided for one service with another. This enabled GoC services, individuals must client controlled sharing of information enrol and identify themselves separately means that the user does not have to re-enter with each government program offering a identity-proofing information so long as it service. This is because privacy policy and can be re-used from a previous enrolment, legislation [PA85] restrict either the central resulting in a faster enrolment process and maintenance of such information, and the an improved user experience. The following sharing of information between government scenario illustrates how this concept would programs. The GoC entities offering the be put into action. The client visits a individual services therefore control their department (Department M) and wishes to “program space” and determine what re-use her authentication that was previously information is required in order for the completed at another department citizen to authenticate him/herself to that (Department D). The client pulls the program. information from the originating department (Department D). Department D prepares the information packet for transmission, elects to pass the information packet onto digitally signing the information packet and the receiving department (Department M). sending it to the client’s browser. The client Thus, by establishing individual consent, can review the information but cannot while retaining other privacy features, the change the information and then the client user experience can be greatly improved. Client reviews and authorizes but cannot change the information Pull info packet into Push the info packet from the browser, signed by the browser, signed by Dept D Dept D to Dept M Dept D Dept M reviews and accepts Dept D’s Dept M authentication procedures during set up (info packet) of the exchange process (info packet) Central Authentication Facility authentications, an assurance level might be Although the Joint Information Exchange assigned to the individual’s profile, and Facility improves the user experience, raised subsequent to successful presentation individual participation is still required to of these shared secrets. As a result, the convey (though not physically enter) their individual registers once and authenticates enrolment information. The purpose of a through the CAF, which shares this Central Authentication Facility (CAF) is to information with departments when the serve as the authentication authority for user individual requests access to specific access to online government services. services. Authenticating individuals on behalf of departments, it could allow users to register While the high-level description given here once for access to the suite of online suggests that technical solutions are readily government services. The following available and straightforward, current scenario illustrates how this concept could legislation would keep it from being be put into action. An individual wishes to operationalised. For instance, the Privacy use two departments’ online services. The Act prevents the collection use and user is directed to the CAF. The CAF disclosure of personal information for collects the individual’s tombstone (e.g. purposes other than those for which it was name, date of birth) and contact information collected. As a result, the simplest way of and requests any additional information as making a CAF happen is that the department appropriate. This then becomes the offering the service would have to individual’s profile. The tombstone and legislatively make it one of its “operating contact information collected by the CAF is programs.” An operating program can be made available to the departments’ defined as a series of functions designed to programs, while for additional assurance, carry out all or part of an entity's operations. the programs may choose to ask for The CAF would then be part of a additional e.g. “shared secret” information department’s line of business, collecting specific to the business of the program, such personal information and authenticating as previously submitted tax information. individuals on behalf other departments Over several program-specific offering online services. User Central Authentication Facility Department Online Service - collects appropriate information Department Online Service - aids in enrolment by sharing info with departments Department Online Service operation will rely heavily on demonstration 3.5 Evidentiary Support for of the environment at the time in question, Electronic Data and more generally, that this environment The admissibility or acceptability of was operated upon using standard protocols electronic data is critical to the success of and procedures. Therefore, in support of our online systems, and therefore critical to evidentiary requirements, sufficient our ability to obtain the purported savings standards need to be defined (and of course and efficiencies. Within the world of PKI, followed). such issues have often been mired in narrow discussions of “non-repudiation.” While While the Canada Evidence Act refers to the ensuring the correctness of technical integrity of “electronic documents”, part 2 solutions is important, we will not obtain our of the 2000 Personal Information Protection goals of supporting electronic data unless and Electronic Documents Act (PIPEDA) the technical solutions fit within the legal, [PIPE00], defines more specific tools policy and business framework for the supporting this integrity, including defining overall online solution in question. And a “secure electronic signature.” As specified while a digital signature is an important, if later in the draft 2004 Secure Electronic not necessary requirement for many Signature Regulations (SESR) [SESR04] applications, a digital signature alone does (which serve as a companion to PIPEDA), a not necessarily provide sufficient evidence. “secure electronic signature […] is a digital If repudiated in a court of law, there is much signature” as constructed using public key information that can contribute to cryptography. The SESR also identify a demonstrating that some action was or was recognition process for a “recognized not performed. The ability to support such Certification Authority” in support of evidentiary needs is as much a question of issuing digital certificates for digital information management and the processes signature production. Though not fully that support this management, and needs to specified at this time, the recognition be driven (at least in part) by the relevant process will rely heavily upon the operating legislation (should it exist). Fortunately, in procedures for CAs as defined in the Canada we have some legislation to help Government of Canada’s Certificate guide the determination of required Policies. evidentiary material. In essence, legislation has provided a first Changes to the Canada Evidence Act step in bridging the legal and technical [CAE04] in 2000 included clauses realms from statutes and regulations to describing the evidence required for “the public key technology. The SESR recognize proof of the integrity of […] electronic the need for a recognition process, and documents” for any “person seeking to additional areas may need to be similarly admit an electronic document as evidence.” addressed. As recognized in the Canada The rules of evidence in this matter weigh Evidence Act (above), further standards will heavily upon being able to demonstrate that help to better support the rules of evidence. “the electronic documents system was For instance, the draft Canadian standard operating properly.” Evidence of proper CGSB (Canadian General Standards Board) 72.34 on “Electronic Records as 4 Concluding Remarks Documentary Evidence,” describes Despite the strides we’ve made in the conditions and practices for good data and development of our e-government solutions, records management which will ensure their we often find ourselves having to justify our evidentiary value and admissibility over selection of PKI. The questions are time. commonly asked by individual departments, and are asked in comparison to the option of Within the model and solutions for Secure a PIN-based SSL solution. Such questions Channel, there are three entities affected by often take one of the following two forms: this legal framework: the Secure Channel operations itself, participating departments, 1. Why should we use a common PKI and the user (citizens and businesses). Each solution instead of developing and has a role and responsibility in ensuring the using our own solution, either with confidentiality and integrity of a PKI or with PIN-SSL? Government On-Line transaction and 2. Why is a PKI solution better than a ensuring that sufficient evidence is collected PIN-SSL solution? with regard to such transactions. The argument for a common solution, versus With regard to the operations of Secure individual department solutions, is often tied Channel, as with any other large to the principle of whether cost savings can infrastructure, there are practical concerns be achieved by building and re-using a regarding what information (records and single solution across multiple logs) needs to be retained, and for how long, organizations. When done properly, this in support of evidentiary requirements. The option has the potential for great savings, retention duration will often relate to and also delegates many issues related to departmental requirements for evidence. managing a solution (e.g. software updates) Work is proceeding in this area, though to the common service provider. However, current evidential areas where standard the benefit of improved user experience processes are described and evidence of should not be overlooked. To many assessments exist include the PKI Certificate citizens, departmental distinctions are often Policies (CPs) and Certificate Practice irrelevant. At least from the point of view of Statements (CPS), the results of Secure their experience, they often just want to Channel Certification and Accreditation, obtain service from “the government,” as design documentation, routine assessments opposed to a particular department. (e.g. ensuring proper CA operation), and numerous audit logs relating to key events With regards to comparisons to PIN-SSL, and for day-to-day operations. the bottom line is that comparisons are often apples-to-oranges, with our established PKI- We are well on our way past the question of based solution, adapted to the policy and non-repudiation, and considering solutions legal regimes of government, compared to to the broader questions of evidentiary some PIN-SSL solution. While a PIN-SSL support, with the legal and business solution could be well implemented, with framework provided with our Government additional functionality and security On-Line solution. It is likely that many of features, there are also a number of poor, ill- the evidentiary requirements are refined defined implementations. However, our through case law, though as in most fundamental needs have always been jurisdictions around the world, we have not consistent, including requirements for yet had sufficient experience with persistent integrity with digital signatures, repudiated digital evidence. persistent confidentiality from end-to-end, support for single sign-on with a single epass, and robust credential management. http://laws.justice.gc.ca/en/p- And our novel variant [Just03] has allowed 38.2/text.html us to overcome, or at least better deal with [GSP02] Treasury Board of Canada, common problems associated with PKI Secretariat, Government [Gut, Gut02]. Security Policy, 2002. Available at With our PKI-based solution, we have thus http://www.tbs- far been able to design and deploy a solution sct.gc.ca/pubs_pol/gospubs/T that fits within the legislative and policy BM_12A/gsp-psg_e.asp framework of the Canadian government, and [Gut] P. Gutmann, “Everything you that has attracted over 285,000 individuals Never Wanted to Know about since 2002. As we move forward, it is most PKI but were Forced to Find often these issues, and not those of Out”; see technology, that present us with hurdles. The http://www.cs.auckland.ac.nz/ issues we identified in the previous section: ~pgut001/pubs/pkitutorial.pdf inter-jurisdictional considerations, business [Gut02] P. Gutmann, “PKI: It’s Not registration, enrolment, and evidentiary Dead, Just Resting”, IEEE support for non-repudiation, attest to the Computer, August 2002; see complexity of assuring secure e-government http://www.cs.auckland.ac.nz/ service delivery in Canada. These and other ~pgut001/pubs/notdead.pdf challenges are not insurmountable, and [Just03] M. Just, “An Overview of indeed the possible solutions we offered Public Key Certificate may contribute to making an already world- Support for Canada's renowned solution even more innovative. Government On-Line (GOL) Initiative”, in Proceedings of 5 References 2nd Annual PKI Research Workshop, April 2003. [PA85] Department of Justice – [CAE04] Department of Justice – Canada, Privacy Act, 1985. Canada, Canada Evidence Available at Act, 1985. Available at http://laws.justice.gc.ca/en/p- http://laws.justice.gc.ca/en/C- 21/text.html 5/15974.html [PIA02] Treasury Board of Canada, [CLF00] Treasury Board of Canada, Secretariat, Privacy Impact Secretariat, Common Look and Assessment Policy, 2002. Feel – Background 2000. Available at Available at http://www.cio- http://www.tbs- dpi.gc.ca/clf-nsi/back- sct.gc.ca/pubs_pol/ciopubs/pi cont_e.asp a-pefr/paip-pefr_e.asp [CSP] Treasury Board of Canada, [PIPE00] Department of Justice – Secretariat, Common Services Canada, Personal Information Policy. Available at Protection and Electronic http://www.tbs- Documents Act, 2000. sct.gc.ca/Pubs_pol/dcgpubs/T Available at B_93/CSP_e.asp http://laws.justice.gc.ca/en/p- [DPW86] Department of Justice – 8.6/text.html Canada, Department of Public [SCF04] B. Watkins, “Secure Channel Works and Government Future”, presentation to Services Act, 1986. Available GTEC Special Forum – at Security, October 20, 2004. [SESR04] Secure Electronic Signature account a business may have. http://www.cra- arc.gc.ca/E/pub/tg/rc2/rc2eq.html#P72_2512 Regulations, draft, Canada Gazette Part I, 2004. 2 The Australian Business Number (ABN) is a unique 11 Available at digit identifier issued by the Australian Tax Office (ATO) to all entities registered in the Australian Business Register. It http://canadagazette.gc.ca/part is used when dealing with the ATO, other government I/2004/20040508/html/regle6- agencies, and when supplying goods and services to other businesses. e.html http://help.abr.gov.au/content.asp?doc=/content/16974.htm& Notes usertype=BC 1 The Business Number (BN) is a 15 character client identification number that consists of a nine digits to identify 3 Here we distinguish between registration – the process of the business and two letters and four digits to identify each obtaining an epass from epass Canada – and enrolment – the action of signing up or applying for a Government of Canada service. Meeting the Challenges of Canada’s Secure Delivery of E-Government Services Mike Just & Danielle Rosmarin Public Works & Government Services Canada 19 April 2005 P u b lic W o r k s a n d T r a v a u x p u b lic s e t G o v e r n m e n t S e r v ic e s S e r v ic e s g o u v e r n e m e n ta u x C anada Canada State of the Nation • Government OnLine (GOL) – Online presence for 130 frequently used programs – Individuals and businesses • Secure Channel (SC) – Common security services to support GOL – Authentication services – Issuance of an “epass” – Approximately 20 GOL programs using SC – Approximately 500K epasses issued to date • Moving forward – Policy, legal and business issues dominate – Issues are critical for us to truly transform our e-government service delivery 19 April 2005 4th Annual PKI R&D Workshop 2 Outline • What is epass? • Areas of Discussion – Inter-jurisdictional issues – Registration of businesses – Enrolment of individuals – Evidentiary Support • Concluding remarks 19 April 2005 4th Annual PKI R&D Workshop 3 What is epass? • An epass is the online credential for individuals and businesses to access Government of Canada (GoC) services • Technically, the epass is a package containing PKI keys and certificates – Certificates are indexed by a Meaningless But Unique Number (MBUN) • An individual can obtain one or more epasses for their interaction with the GoC 19 April 2005 4th Annual PKI R&D Workshop 4 What is epass? (2) • Establishing the relationship between an epass and a GoC program (e.g. Canada Revenue Agency) 1. Individual registers to obtain their epass • Obtained from a common Secure Channel service • No identification takes place at this stage 2. Individual enrols with a GoC program • If required, identification takes place with GoC service • The MBUN is indexed with the existing program identifier (PID), and mapping is maintained by the program • Key drivers • Privacy, security and usability • Meeting the business requirements of government programs 19 April 2005 4th Annual PKI R&D Workshop 5 What is epass? (3) Central CA Program Specific Repositories UserID Encrypted Creds J1969 XXXXXXXXX Program A MBUN PID 1035 123456 Program B MBUN PID 1035 133498 Program C MBUN PID 1035 998321 19 April 2005 4th Annual PKI R&D Workshop 6 Areas of Discussion • While technical innovation is always required, our issues today relate to policy, legal and business concerns • Four areas of interest – Inter-jurisdictional issues – Registration of businesses – Enrolment of individuals – Evidentiary Support 19 April 2005 4th Annual PKI R&D Workshop 7 Inter-jurisdictional • Public Works and Government Services Canada (PWGSC) is a federal department • But citizens have a relationship with all levels of government, including provincial and municipal 1. Till recently, PWGSC legislation limited the selling of services to other jurisdictions • Recently resolved through an “Order-in-Council” by Canada’s head of state (Governor-General) 2. Differing policy and standards across jurisdictions • Common Look and Feel (CLF) 19 April 2005 4th Annual PKI R&D Workshop 8 Registration of Businesses • Potential to process differently than individuals – Same epass process used for both now • Currently, a business can have multiple identifiers for interacting with the GoC – Business Number (BN) is legislatively limited to use for tax purposes only – Potential solutions include legislative changes, or adopting a new number (e.g. like the Australian Business Number) • Separate enrolment with each government program – Potential option for information sharing solution – Potential option for centralized enrolment 19 April 2005 4th Annual PKI R&D Workshop 9 Enrolment of Individuals • Current epass solution was designed to be privacy- friendly – Pseudonymous epass credentials – No personal information collected nor stored centrally – Identification remains within each government program • However, – Individuals must enroll at each program – Not all programs are able to enroll online (e.g. they lack sufficient shared secrets) • Require a solution that respects the privacy climate within Canada 19 April 2005 4th Annual PKI R&D Workshop 10 Enrolment of Individuals (2) • Joint Information Exchange Facility 2. Client reviews & authorizes but cannot change the information 1. Pull info packet into 3. Push the info packet from the browser, signed by the browser signed by Dept D Dept D to Dept M Dept M reviews and accept Dept D’s authentication procedures during set up of the exchange process Dept D Dept M (info packet) (info packet) 19 April 2005 4th Annual PKI R&D Workshop 11 Enrolment of Individuals (3) • Central Authentication Facility Dept Online Service Central Authentication User Facility Dept Online Service - Collects appropriate info Dept Online Service - Aids in enrolment by sharing information with department • Likely not a viable solution for today’s privacy climate 19 April 2005 4th Annual PKI R&D Workshop 12 Evidentiary Support for Electronic Data • Requirements for evidentiary support for electronic transactions must be driven by policy, legal and business requirements, not technology • Recent legislative changes to support electronic data as evidence – Canada Evidence Act (2000): Proper operation of electronics document system – Personal Information Protection and Electronic Documents Act (PIPEDA) (2000): Electronic signature • Secure Electronic Signature Regulations (2005): Digital signature • Standards, and operation within those standards, are key to demonstrating the integrity of electronic data 19 April 2005 4th Annual PKI R&D Workshop 13 Concluding Remarks • Currently have a sound solution with epass • Recognize that the effective delivery of e- government services requires that certain challenges be addressed • Potential for similar issues to arise for other (government) solution providers • Recognition of the importance of the policy, legal and business context when designing technical solutions 19 April 2005 4th Annual PKI R&D Workshop 14 The Use of PKCS-12 in the Federal Government The PKCS 12 standard built upon and extended the Tice F. DeYoung, PhD 1993 PKCS 8: Private-Key Information Syntax National Aeronautics and Space Administration Standard [2] by including additional identity information along with private keys and by instituting higher security through public-key privacy and INTRODUCTION integrity modes. The PKCS 8 standard described syntax for private-key information, including a The purpose of this paper is to provide a brief private key for some public-key algorithm and a set description of the history of the Public-Key of attributes, as well as, syntax for encrypted private Cryptography Standard number 12, or PKCS-12, the keys. Personal Information Exchange Syntax, for exporting public key infrastructure (PKI) private keys and The PKCS-12 standard describes a transfer syntax for certificates; to investigate the implications of using personal identity information, including private keys, this mechanism as they apply to the Federal PKI certificates, miscellaneous secrets, and extensions. Policy Authority; and to present a set of conclusions Applications that support this standard will allow a which are not recommendations per se, but are rather user to import, export, and exercise a single set of a list of things to consider before one permits end personal identity information. This standard supports users to export their PKI private keys and certificates direct transfer of personal information under several using PKCS-12. privacy and integrity modes, the most secure of which require the source and destination platforms to have trusted public/private key pairs usable for digital BACKGROUND signatures and encryption, respectively. PKCS 12 permits both software and hardware implementations. Before we describe PKCS 12, we should first Hardware implementations offer physical security in mention what the Public-Key Cryptography tamper-resistant tokens such as smart cards. [1] Standards are. These specifications are produced by RSA Laboratories in cooperation with a number of developers worldwide for the purpose of accelerating FEDERAL PKI POLICY AUTHORITY the deployment of public-key cryptography. The first PKCS was published in 1991. Since then the PKCS The Federal PKI Policy Authority (FPKI-PA), under documents have become widely referenced and the auspices of the Federal Identity and Credentialing implemented. Committee (FICC), is responsible for the policies of the various Federal PKI implementations; the Federal PKI Bridge CA (FBCA), the Common Policy THE PKCS-12 STANDARD Framework CA (CPFCA), the eGovernance CA (eGOVCA) and the Citizen and Commercial Class To understand how PKCS-12 came about, we have to CA (C4A). This paper will only discuss the go back to 1995. At that time all of the encryption relevancy of the FBCA and its concomitant software was proprietary and there was no Certificate Policy to the use of PKCS 12. mechanism for people to securely communicate unless they had the same product. This lack of The Federal Government is required to use interoperability was recognized by a number of cryptographic modules that have been accredited as people. meeting the NIST Federal Information Processing Standard 140 level 2 (FIPS 140-2) accrediting There were several development options that could process [3]. Additionally any entities PKI that want lead to interoperability. First, you could set up a new to cross-certify with the FBCA must follow US application specific certificate authority (CA) to issue Government PKI Cross-Certification Methodology PKI certificates for every user of that application. and Criteria. [4]. Once an entity PKI has completed Second, you could develop application specific plug- this process, they are required to sign a Memorandum ins for every other application. Because each of of Agreement (MOA) with the FPKI-PA, which lays these options leads to unnecessary complexity and/or out the rights and responsibilities of both parties. expense, the community arrived at the best option; One of the items in every MOA is the requirement they all agreed that a single standard should be dev- that the entity PKI cross-certifying with the FBCA eloped. That standard came to be known as PKCS shall maintain compliance with the requirements in 12, published by RSA Laboratories in 1999. [1] the MOA and shall notify the FPKI-PA if any material changes occur. ISSUES WITH THE USE OF PKCS-12 in the PKI application and when the data is exported using PKCS-12. The FBCA Certificate Policy [5] is silent on the use of PKCS 12, so that its use does not apparently Now things begin to get interesting. While within the violate any of the requirements in the MOA. PKI application, the keys and certificates are However, as we will discuss later, there are issues centrally controlled and managed. However, when associated with private key protection and activation, the PKI data is exported, the PKI applications are which are application specific that must be addressed. now unable to provide this management because they One of the questions that arises is whether or not an have no control of the portable PKCS-12 container, entity must notify the FPKI-PA if it intends to use nor do they control what applications and devices the PKCS 12; another is whether the entity must notify private keys and certificates are imported into. The the FPKI-PA of every application that it intends to end user is the only one who can control things once import the PKI secret keys and certificates into. they have been exported. Therein lies the rub! The There are others, which will be discussed in more end users will have to maintain consistency between detail in the following sections. their keys and certificates that have been exported and those that are still within the PKI application. Exporting the private keys and certificates isn’t the They will have to keep track of updates, key rollover, problem. PKI applications that follow the PKCS-12 what applications and devices they have exported standard keep the exported data in an encrypted state. them to, etc. They are also the only ones responsible To further explain this, let me use an analogy. Let’s for determining if the applications and devices meet assume that the PKI application is equivalent to a the FIPS 140-2 requirements. How can we ensure safe, because the private keys and certificates are that the end users maintain their exported PKI data in maintained securely, in one place and easy to a manner consistent with their CP and CPS and their centrally manage. When the information is exported, FBCA MOA? it is no longer in the safe, but is in a portable lock box, or secure briefcase, which is portable. The This brings us to the next section of this paper, container is protected, so that doesn’t cause a namely the things one should consider before problem. However, the portable container can be allowing end users to use the PKCS-12. used in an insecure fashion if it isn’t carefully controlled. THINGS TO CONSIDER Let me use as an example the FBCA CP Medium Level of Assurance requirements. The FBCA CP First and foremost, you do not want to do anything requires private keys to be protected with FIPS 140-2 that will cause your use of PKCS-12 to violate the accredited devices and applications for cross- level of assurance of your CA and, if you are cross- certification at the Medium Level of Assurance. I certified with the FBCA, you don’t want to use this example because the overwhelming majority jeopardize the MOA requirements you have with the of entities cross-certified with the FBCA and those FPKI-PA; so tread carefully if you do decide to who have applied for cross-certification have been at permit PKCS-12 export of private keys and this level. Furthermore, the Medium Level of certificates. Assurance at the FBCA covers both Levels 3 (software PKI) and 4 (hardware PKI) as outlined in What are the benefits of permitting the use of PKCS- the OMB Guidance on Authentication Levels[6] and 12 mechanism for exporting private keys and the associated NIST Electronic Authentication certificates? One that comes quickly to mind is that Guideline[7]. For this example I am assuming that it permits you to import them into the Blackberry the PKCS 12 exported PKI data is secured in Personal Digital Assistant (PDA) beloved by upper accordance with FIPS 140-2. Therefore, exporting level management in most Federal agencies. These the PKI data from the PKI application (safe) to the devices are ubiquitous throughout the ranks of these PKCS-12 container (secure briefcase) has not Senior Executives who tend to be the least versed in violated the FBCA CP requirements. One of the information technology security issues. We have to FBCA CP requirements is that passwords used to provide them and their data without bothering them unlock access to the private PKI keys must be at least with details or interfering with their ability to 8 characters in length and contain at least one from properly lead their agencies. each of the following categories (upper case, lower case, numbers and special characters). This Blackberries are only the tip of the iceberg when it requirement is easily met when the private key data is comes to PDAs. There will soon be smart phones, other intelligent PDAs and possible Personal Access H. Develop a Supplemental Networks (PAN). The one thing they have in Subscriber Agreement that common is wireless connectivity. Wireless access describes points will rapidly follow and we will have to provide their additional adequate security for these devices using some form responsibilities and notifies of cryptographic mechanism. Having the same them that private keys and certificates for the myriad devices extra training is required. and applications is an efficient way to easily manage this. PKCS-12 gives you that capability. Here are some things you might want to include in the additional training for your users who want to use Now, what can you do to ensure that giving your PKCS-12. Again, this list is for illustrative purposes users this capability doesn’t compromise your only and should not be considered to be all-inclusive: security and thus your level of assurance? First, review your CP and CPS to see if there are any A. Describe their responsibility changes required. Note that if you are operating at for and methods of the High Level of Assurance, you cannot permit the managing use of PKCS-12 export or you will violate your their exported keys and policies. Second, notify the FPKI-PA of your certificates; intention and the steps you will take to ensure that B. Explain that the users can you do not violate your level of assurance. Next, only import their private consider additional procedures and processes for the keys subscribers that will use PKCS-12 export. Here are a and certificates into few suggestions, but his list is far from complete: applications and devices that their A. Put thePKCS-12 users in a PA has approved as meeting separate group; FIPS 140-2 requirements; B. Use a separate OID in their C. Describe the processes and X.509 certificates; procedures to followed for C. More closely audit their exporting and importing usage; their PKI data; D. Require additional training in managing their private keys CONCLUSIONS and in the procedures for exporting and importing As we stated at the beginning, we are providing no them; conclusions or recommendations on the use of E. Require subscribers to obtain PKCS-12; but instead, have briefly discussed some permission from your things to consider before embarking into the brave agency Policy Authority new world of permitting users to export their PKI (PA) before importing their private keys and certificates using the PKCS-12 private keys and certificates export mechanism. into an application or device; F. Develop a list of FIPS 140-2 However, for your information, we at NASA have approved applications and carefully weighed the attractive benefits and the devices that would be the potential dangers of permitting users to export their basis for your PA decisions private keys and certificates and have made the in E.; decision to permit certain users to use PKCS-12. We G. Issue their credentials at the are now implementing some of the above steps to Basic Level of Assurance, ensure that we do not compromise our security. We but are cautiously optimistic that things will proceed only if absolutely necessary smoothly. to maintain cross- certification REFERENCES [1] PKCS 12 v1.0: Personal Information Exchange Syntax, RSA Laboratories, June 24, 1999. [2] PKCS 8: Private-Key Information Syntax Standard, RSA Laboratories, November 1, 1993. [3] Security Requirements for Cryptographic Modules, NIST FIPS 140-2, December 3, 2002. [4] US Government PKI Cross-Certification Methodology and Criteria, March 2003. [5] X.509 Certificate Policy for the Federal Bridge Certification Authority, 27 September 2004. [6] E-Authentication Guidance for Federal Agencies, OMB 04-04, December 16, 2003. [7] Electronic Authentication Guideline, NIST Special Publication 800-63, v. 1.0, June 2004. Secure Access Control with Government Contactless Cards David Engberg CoreStreet, Ltd. One Alewife Center, Suite 200 Cambridge, MA dengberg@corestreet.com Abstract—Government agencies have begun Once your identity is determined, the system must widespread usage of public key technology for answer a second question: “Are you currently allowed information security applications such as secure email, to access this resource?” This question is answered document signing, and secure login. These deployments through a process called authorization or validation. use PKI tokens in the form of contact smart cards with Unlike authentication, which should always yield the private keys protected through a match-on-card second same identity for each person, the result of factor such as a PIN. More recently, the government has authorization may change frequently. This change may begun to standardize card technology for contactless be the result of a change in user privileges (e.g. a physical access. These contactless cards will be capable of promotion), a change in policies, or a change in the symmetric key usage, but will not be able to perform environment (e.g. time of day, etc.). private key operations. They will also typically be limited This document describes techniques and to 1-4kB of read/write data storage. technologies that can be used to perform secure access This paper discusses ways to use digitally signed control using the current generation of government messages to perform strong authentication and contactless cards. This focuses on solutions that will support cards based on ISO 14443 Parts 1-4 [ISO01], authorization using the current generation of contactless smart cards. This will compare different strategies under such as those using Philips’ DESFire chips. These consideration and discuss the security and usability cards comply with NIST’s Government Smart Card Interoperability Specification (GSC-IS) version 2.1, considerations of each. Particular emphasis is placed on techniques to support the use of these cards in inter- Appendix G [SDW+03]. The general techniques agency and offline settings. described in this document should also be applicable to other contactless memory cards, including those with Keywords—contactless, smart cards, biometrics, access other symmetric key schemes (e.g. HID’s iClass). control The techniques described in this document are primarily compared in their ability to permit strong 1 OVERVIEW authentication and authorization within federated There are two questions that must be answered by environments where a single central access control an access control system before permitting access. The system is not possible. This support for federated first question is: “Who are you?” The answer to this access control also leads to the ability to perform question is your identity, which is permanent authentication and authorization in disconnected throughout your life. The process of answering this settings where no communication is available to central question, authentication, must rely on one or more management servers. factors to uniquely determine your identity. These factors are typically divided into three categories: Something you have: E.g. a badge, a metal key or a 2 SECURE CONTACTLESS AUTHENTICATION smart card The process of authentication uses one or more Something you know: E.g. a PIN or a password factors to securely determine the identity of a cardholder. These factors may be fully independent Something you are: E.g. your fingerprint, your iris or (printed photo, contactless card serial number), or may your voice be interconnected (e.g. contact chip PIN and PKI An access control system authenticates these factors applet). An effective authentication factor will to identify each user. Since your identity never uniquely and unambiguously identify a specific changes, the process of authentication should always individual, binding to their universal identifiers. yield the same result, even if the factors used may Different authentication factors also vary in their level change. of protection against modification or duplication. Finally, some factors that may be appropriate in a closed environment with guaranteed network connectivity may not be usable in federated or By implementing ISO 14443 directly, an attacker can disconnected settings. imitate any desired CHUID. Digitally signed CHUIDs The following sections describe various factors that prevent the assembly of arbitrary false identifiers, but may be used with contactless DESFire cards to perform this does not provide any protection against the complete duplication of a valid CHUID onto another authentication. real or emulated card. 2.1 DESFire card unique identifier (CUID) A stored identification string only represents a basic Every DESFire card is manufactured with a unique assurance factor for authentication. and read-only card unique identifier (CUID), which is made up of a one byte manufacturer code (e.g. Philips: 2.3 Symmetric key authentication 0x04) and a six byte card number that is set by the High-end ISO 14443 cards such as the DESFire manufacturer. Barring a manufacturing error, no two offer strong mutual authentication and over-the-air legitimate DESFire cards should have the same CUID. encryption using symmetric (secret) keys. For The card CUID can be retrieved by any ISO 14443 example, a DESFire application can be configured to only permit access by reader that knows a secret Triple- reader within range of the card. This CUID is read in clear text form during the card selection and anti- DES key that is stored on the card itself. Only readers collision processing, which precedes any other card that know this shared secret key are capable of accessing the application. Separate keys may be actions. enabled for different types of operations (reading, Pro: The serial number is unique and unambiguous. writing, card management) on each card. The UID of a legitimate card cannot be modified. Typically, each card has its own secret key or keys Con: The serial number has no cryptographic or which can be derived using an application “master key” protocol-level protections to prevent an attacker from (which is present on every reader) and some other card- asserting the same serial number as any real card. By specific identifiers (such as the card serial number). implementing ISO 14443 directly, an attacker can This means that each card doesn’t have the same secret imitate any desired CUID. key, so a compromise of one card’s key does not The CUID only represents a basic assurance factor compromise any other cards. On the other hand, every for authentication. reader in a domain must share the same master key(s). Pro: Strong “something you have” factor for 2.2 Stored identification string smaller environments. Key cannot be copied or cloned In addition to the manufacturer’s CUID, it is without access to domain master key. possible to write a more extended identification string Con: Access to master key would compromise into the card memory that represents the cardholder. every card in that domain, permitting duplication of any Example encodings would include a SEIWG-012 string card and access to any reader. Key protection issues [SEIWG02] or a PAIIWG Card Holder Unique significantly constrain the number of places that this Identifier (CHUID) [PAIIWG04]. Under current authentication factor can be used. Cross-domain proposals, this string would be written to the card in a authentication in federated environments is largely known location where it would be generally available in impractical, particularly in disconnected environments a “read-only” mode. due to master key management issues. These identification strings can contain a larger Symmetric keys on cards represent a high assurance amount of unique identification such as organizational factor for authentication in closed environments, but are affiliation and unique personnel identification number not secure for use in inter-agency or disconnected within that organization. environments. A digital signature on the CHUID by a trusted authority can be used to prevent the forgery of modified 2.4 Raw biometric templates CHUIDs. Some deployments of contactless storage cards such Pro: For legitimate cards issued by the government, as DESFire use biometric templates to perform a stored identification string such as a SEIWG-012 authentication using a “something you are” offers a unique identifier that also includes affiliation authentication factor. They do this by storing a raw information for cross-organizational interoperability. biometric template in the card storage area in a read- This string cannot be modified on a valid card without only form. This template can be read off the card and access to the issuer’s master key. compared against a user to help confirm the identity of the user. Con: The stored identifiers are not strongly bound to either the cardholder or the physical card, so they This template can be represented using an older may be easily duplicated or imitated onto another card. proprietary scheme, or could use forthcoming standard representations defined under ISO/IEC 19794 [ISO04] template(s) and the card itself. As long as the CUID is or INCITS 377+ [INCITS04]. treated as the primary identifier for the user, this Pro: The biometric is tightly bound to the user. provides protection against the transfer of identity to other cards. Con: The biometric is not bound to the card or any identifying serial number, so it may be trivially copied Pro: Adding the card’s CUID into the signed to another card or emulator. This does not offer a interchange file provides a strong binding to a unique identifier which mitigates against copying templates useful identification factor in inter-agency or disconnected environments. The lack of any between cards. cryptographic protection would allow any biometric to Con: The CUID identifier may not be a sufficient be presented from a card. reference ID for interoperability, since the CUID may Raw biometric templates constitute a low assurance not be securely known by other entities. This identifier is also not tied into the digital identity represented on factor due to their lack of strong binding and copy protection. the contact half of the card. As in Error! Reference source not found., above, this representation will be expensive in either IO times or memory if more than 2.5 Signed biometric interchange files one biometric template is stored on the card. Rather than storing raw biometric templates on cards, some groups have promoted the storage of one or Adding the external CUID into the signed message more biometric templates on the contactless card with a provides a high assurance authentication factor. digital signature to protect them from modification. These files would typically be written using a 2.7 Signed biometric templates with card ID and standardized signed interchange format such as CBEFF certificate binding [PDR+01] or X9.84-2003 [ANSI03]. To provide a stronger binding to the user’s overall Pro: The basic representations in these standards digital identity, it would be straightforward to extend provide a digital signature around the biometric the logical scheme proposed by the Interagency template, which prevents the creation of arbitrary Advisory Board Data Model Task Force to bind the templates for non-registered users. biometric template to both the card (via CUID) and the user’s more general digital identifier [IAB04]. This Con: Standard CBEFF and X9.84 do not provide could be done by including the relevant serial number strong binding to the card or any identification factors. and issuer information from the cardholder’s The biometric template for any registered user can be Identification digital certificate. This would provide copied to another real or emulated card, which provides binding to a universal unique identifier which would be no protection against duplication. Once a user has been strongly represented on both the contact and contactless registered (so they have a signed biometric template), interfaces. they can reuse the generated interchange file indefinitely. In addition, if the card contains more than The stored biometrics could be bundled together one biometric template, the reader must retrieve all of with this identifying information and bound using a the biometric values (the entire CBEFF) before single digital signature, as shown in Figure 1, below. signature validation can be performed, which will negatively impact transfer speeds for the user. If each biometric template were split into a separate signed file, the time to retrieve one template would be reduced, but the total storage requirement would increase significantly due to the overhead from the interchange file format (dozens of bytes) and the digital signature (approximately150 bytes for RSA-1024). Simple signed biometrics provide only basic assurance for interoperable and disconnected environments. 2.6 Signed biometric interchange files with card ID binding Groups such as the Interagency Advisory Board task force are considering extending biometric interchange formats such as CBEFF to include the card serial number (CUID) in the signed CBEFF body to provide a stronger binding between the biometric could be as simple as adding a certificate identifier field into the IAB proposal. Format metadata Alternately, a different encoding could be used. For Card serial number (CUID) example, an X.509 Attribute Certificate [ISO01b] Identity PKI certificate ID would provide a signed, extensible data format that (Issuer ID, cert serial uniquely binds the cardholder’s identity certificate to one or more biometric templates, the CUID, and any other issuer-defined fields as needed. This would offer Biometric metadata #1 compatibility with existing standards and encodings Biometric template #1 with greater future flexibility. Pro: Binding the biometric to the card’s CUID and the user’s cert ID provides a mapping that ties the biometric, the card, and the high-level digital identity of Biometric metadata #2 the user. This also permits a unified approach to identity management and validation, since the cert ID Biometric template #2 can serve as a universal identifier for all transactions. This could allow inter-agency identification through a federated identity instead of relying on pre-registration. … Con: If more than one biometric template is stored on the card, then this scheme will be either inefficient Digital signature in data transfer times or storage usage. If one signature encapsulates all templates, then all templates must be Figure 1 transferred before any can be used. This may consume a significant amount of time due to the limited data Alternately, each separate biometric template transfer rates for contactless cards. If, on the other (fingerprints, hand geometry, iris scans) could be stored hand, each template is put into a separate digitally in a separate digitally signed format that is bound to the signed file, then the retrieval of one template is card and user, as shown in Figure 2, below. efficient, but a significant portion of the limited memory capacity of the card will be wasted with redundant data and extra digital signatures. With either representation, digitally signed Format metadata biometrics bound to cert and card IDs represent a high Card serial number Format metadata assurance authentication factor. (CUID) Card serial number 2.8 Signed biometric references with card and cert (CUID) ID binding Issuer PKI cert ID (Issuer ID, cert serial As an optimization to the bound biometric templates number) Issuer PKI cert ID described in 2.7, above, CoreStreet believes that the (Issuer ID, cert serial data storage and bandwidth aspects of signed, bound number) templates can be reconciled by signing secure Biometric references to biometric templates rather than the metadata #1 templates themselves. Biometric Biometric metadata #2 Under this scheme, a digitally signed authentication template #1 file (e.g. Attribute Certificate) would be placed onto the Biometric card. Like the previous architecture, this message template #2 would bind together the card CUID, the cardholder’s Digital signature identity cert ID, and biometric information. However, Digital signature rather than storing the entire biometric templates within the signed authentication file, this scheme would only store a one-way secure hash of each biometric template, Figure 2 as shown in Figure 3, below. This logical representation could be expressed through a CBEFF Patron format in the same manner as the IAB’s proposed data format. This representation Biometric Using this scheme, a reader capable of Format metadata metadata #1 authentication using a particular biometric technology (e.g. Iris scan) could initially read File #0 to retrieve the Card serial number Biometric signed master authentication file. This would contain (CUID) template #1 strong binding to the card (which would be verified against the retrieved CUID) and the user’s digital Issuer PKI cert ID identity (attribute certificate). This initial file would be (Issuer ID, cert serial relatively small (200-300 bytes) since it does not number) Biometric contain any of the biometrics. metadata #2 Biometric #1 type & Biometric After reading and verifying the authentication master file, the reader could determine that the desired hash template #2 template type (iris template) is located in File #3. This Biometric #2 type & template could be retrieved without touching any of the hash other biometric templates on the card. Its integrity Biometric #3 type & Biometric could be confirmed by hashing its bytes and comparing hash metadata #3 against the master authentication file. … Biometric Pro: Permits strong authentication in federated and template #3 disconnected environments with minimum of wasted Digital signature data and communication. Optimal scheme when multiple independent biometrics are represented on the Figure 3 card. Con: Small storage overhead (~30 bytes) if only a Using this scheme, the card stores a single single biometric template is stored on the card. Data authentication file, with a single copy of the binding model and representation not defined by existing information and the digital signature. For each standard (e.g. CBEFF). biometric template on the card, this authentication file will contain a indicator of type (e.g. INCITS 377 Use of this type of strongly bound signed biometric Fingerprint Minutiae template) and a one-way secure represents a high assurance authentication factor. hash of that particular biometric file. This would only add around 30 bytes per biometric to the base 2.9 Contactless PKI authentication file. For comparison, it must be noted that cards are currently available that can perform asymmetric The biometrics themselves would be each stored in operations on a contactless (ISO 14443) interface. For a separate file on the card. Each biometric would be example, Oberthur currently distributes FIPS-certified unsigned. However, the single signature on the contactless cards based on Philips chips that can authentication file could be used to confirm the perform RSA operations on both contact and integrity of any of the referenced biometrics. We contactless interfaces. While this technology has not would recommend that the individual biometric been selected for the current generation of government templates be stored in separate card files in the same smart cards, the protocol-level compatibility could order that they are represented in the authentication file. permit a simple transition in the future. For example, an application could be provisioned on the DESFire card with the following files: These contactless capabilities could be enabled by either linking the contactless antenna to the contact chip (dual-interface) or else by integrating an independent File ID: 0 Signed authentication file (e.g. Attribute contactless chip (combo card). Certificate) Pro: Provides strong authentication without requiring access to biometric information. File ID: 1 Biometric template file #1: Finger #1 minutiae Con: Dual-interface cards may introduce security and privacy concerns if access becomes available to File ID: 2 Biometric template file #2: Finger #2 sensitive applications on the contact chip. Combo cards minutiae may significantly increase per-card costs over simpler symmetric chips like DESFire. File ID: 3 Biometric template file #3: Iris template Use of contactless cards with private key … … capabilities would represent a high assurance factor. 3 BIOMETRIC CONSIDERATIONS The ability of an attacker to forge a biometric authentication factor depends on the countermeasures The previous descriptions of biometric-based provided by the biometric vendors. For example, authentication assume the existence of ideal biometric advanced fingerprint sensors attempt to detect the algorithms that are acceptable for widespread usage. difference between live fingers and duplicates using For real-world applications, the use of biometric proprietary detection of temperature, moisture, templates may introduce several issues. conductivity, etc. 3.1 Privacy 3.3 Interoperability The collection of biometric information by In spite of ongoing efforts to standardize biometric government agencies can raise concerns that this data templates and sensors, unacceptable incompatibilities may be misused. For example, a database containing may exist between templates and algorithms from the fingerprint templates of all government-affiliated multiple vendors. It is believed that these individuals could be a tempting target for someone interoperability issues will improve as the relevant wishing to establish the owner of a latent fingerprint. standards are finalized, but this may not provide an Similarly, a database of face images could be searched adequate solution for the current generation of cards. to identify lawful protestors. This may require a fallback from efficient This concern for biometric searches (1-to-N) may representations (e.g. fingerprint minutiae) to bulkier be lessened by an approach that only stores biometric forms (e.g. full fingerprint images) that may exceed the information on user cards. The schemes, above, would storage capacity of contactless cards. permit an attacker up to a meter away from a user to silently pull the user’s biometric templates along with the user’s serial number(s). 4 SECURE CONTACTLESS AUTHORIZATION This attack should be contrasted with the ability of a If contactless authentication is performed using only nearby attacker to gather equivalent data through more factors that are bound to the card’s serial number (CUID) or domain-specific authentication string (e.g. prosaic means. For example, a facial image on the card would be more difficult to capture than a snapshot from CHUID), then any solutions to validate and authorize a digital camera. A fingerprint template would be no the cardholder will be inherently limited to the physical access domain, since there is no strong tie to the digital easier to retrieve than a latent fingerprint left by the cardholder. identity represented on the contact interface of the card. If, however, the authentication is tightly bound to More importantly, the biometrics on the card should not be tied to identifying biographic information. The the cardholder’s digital identity, as represented by their schemes, above, recommend binding the biometrics identification public key certificate, then the same unique identifier can be used for both contactless only to arbitrary serial numbers, not biographic identifiers such as name or social security number. physical access and contact PKI transactions. This means that a passive reader in the Pentagon Metro This property permits a unified approach to securely station may be able to silently retrieve a large number managing the privileges and revocation of a cardholder. of government fingerprint templates, but these would be For example, OCSP [MAM+99] or CRLs could be used no more useful for building an identification database to determine whether the cardholder has been revoked, than random fingerprints from the subway’s poles. and this same scheme would be usable for both physical and logical access. Privileges could be securely 3.2 Forgery delivered for use in both physical and network Another possible concern with the use of biometric environments. templates is the potential for an attacker to use the template as a basis for a forged biometric that could fool some sensors. For example, a facial image suitable for face recognition could also be used to create a printed image capable of fooling some face recognition systems. This property of biometrics also prevents the effective revocation of the biometric factor if it is ever compromised. Unlike a private key, which can be revoked and replaced, a duplicated finger cannot be comfortably discarded. OCSP Response Cert ID: 1234 Status: Valid Expires: 1/7/05 17:00 Contactless authentication Contact-chip authentication (bound biometrics) (X.509 digital certificate) Format metadata Cert issuer Card serial number Cert subject Identity PKI certificate ID Serial number (Issuer ID, cert serial number) Public key Biometric #1 type & hash Extensions Biometric #2 type & hash … … Digital signature Digital signature Figure 4 Each authorization message is strongly bound to the 4.1 Unified authorization messages cardholder’s digital identity by including the Figure 4 shows the same authorization message, in cardholder’s identity certificate ID within the signed the form of a digitally signed OCSP Response, being message body. Any reader can inspect the used for physical and logical access for the same card. authorization message to confirm its integrity and This authorization message could be represented using timeliness, and then use the validation and privilege any other desired standard such as a digitally signed information to grant access. SAML assertion [OASIS02], an X.509 attribute certificate, etc. Rather than proscribe a particular authorization message format for the entire government to permit This scheme also provides a smooth migration to inter-agency and offline authorization, CoreStreet dual-interface cards where the same general recommends that the government permit the allocation applications would be available though either the of a reusable “authorization container” on the contact or contactless (T=CL) interfaces. By logically contactless card that may be used to store any identifying users using their cert ID today in a DESFire authorization information used within an individual contactless environment, there is an easier migration to organization. a future when the public key identity applet itself is available for secure asymmetric challenge-response Figure 5 shows the structure of a possible general authentication. authorization container on a contactless DESFire card. 4.2 Offline authorization If authentication factors such as signed, bound biometrics are available on the contactless interface, then strong authentication can be performed in offline settings without any access to an online directory. Similarly, secure authorization can also be performed in offline settings by storing signed authorization messages on the contactless interface. 5 CONCLUSIONS ... other applications … The current generation of contactless identification cards have limitations which make it difficult to provide AID strong authentication for large, federated environments. F51230: Authorization Application Various approaches achieve different choices to balance scalability, security, and performance for physical Authorization message file access control. If strong authentication is required for federated OCSP Response environments, we believe that this can only be achieved using either strongly bound biometrics or contactless Cert ID: 1234 public key support. Unfortunately, these approaches Status: Valid may run into issues of privacy and cost which could prevent them from being adopted. Lower-assurance Expires: 1/7/05 17:00 alternatives may result in a higher risk of compromise through cloned identification credentials. Strong federated authorization, on the other hand, may be possible under either scheme through the use of signed authorization messages for access control. Optional additional files … 6 REFERENCES [ANSI03] American National Standards Institute. ... other applications … Biometric Information Management and Figure 5 Security for the Financial Services Industry. ANSI X9.84-2003. 2003. For example, the inter-agency standards bodies [INCITS04] InterNational Committee for Information could define an application identifier (AID) and file Technology Standards. Information number which has free read/write access. A cardholder Technology – Finger Pattern Based with this applet could arrive at one agency, which may Interchange Format. January 2004. put a signed OCSP response onto her card to indicate validity and privileges. Offline readers in that agency [IAB04] Interagency Advisory Board (IAB) Data would retrieve this OCSP message and use it to Model Task Force. IAB Data Model determine access privileges. At a second agency, the Task Force Report v0.6 (Draft). October cardholder’s card may be loaded with a signed SAML 2004. assertion of the user’s privileges, which would be used [ISO01] International Standards Organization. to determine access at offline readers within that second Identification cards – Contactless agency. integrated circuit(s) cards – Proximity The three important characteristics of this cards – Parts 1-4. ISO/IEC 14443. authorization container are: 2000-2001. • Standardized location on the card (3-byte AID on [ISO01b] International Standards Organization. DESFire cards) Information technology – Open Systems Interconnection – The Directory: Public- • Unrestricted read/write access key and attribute certificate frameworks. • Sufficient space for signed data (ideally, at least ISO/IEC 9594-8. August 2001. 1kB) [ISO04] International Standards Organization. In Figure 5, the authorization message file is Information technology -- Biometric data currently holding an authorization message in the form interchange formats. ISO 19794. Under of an OCSP Response, but the authorization message development, 2004. could be any digitally protected format that is strongly [MAM+99] M. Myers, R. Ankney, A. Malpani, S. bound to the identification credential. Galperin, C. Adams. X.509 Internet This scheme would permit the greatest flexibility Public Key Infrastructure Online for supporting inter-agency and offline authorization by Certificate Status Protocol – OCSP. allowing each organization to locally specify their IETF RFC 2560. June 1999. chosen representation, while guaranteeing that the card [OASIS02] Organization for the Advancement of hardware in use by different agencies will interoperate. Structured Information Standards (OASIS). Guidelines for using XML Brigitte Wirtz. CBEFF: Common Signatures with the OASIS Security Biometric Exchange File Format. Assertion Markup Language (SAML). NISTIR 6529. January 2001. Draft 02. September 2002. [SDW+03] Teresa Schwarzhoff, Jim Dray, John [PAIIWG04] Government Smart Card Interagency Wack, Eric Dalci, Alan Goldfine, Advisory Board’s Physical Security Michaela Iorga. Government Smart Interagency Interoperability Working Card Interoperability Specification, Group, Technical Implementation Version 2.1. NIST Interagency Report Guidance: Smart Card Enabled 6887. July 2003. Physical Access Control Systems, [SEIWG02] Security Equipment Integration Working Version 2.2. July 2004. Group, US Department of Defense. [PDR+01] Fernando Podio, Jeffrey Dunn, Lawrence Access Control Technologies for the Reinert, Catherine Tilton, Lawrence Common Access Card. April 2004. O’Gorman, M. Paul Collier, Mark Jerde, Secure Access Control with Government Smart Cards Dave Engberg CoreStreet, Ltd. dengberg@corestreet.com © Copyright 2004 CoreStreet, Ltd. Road Map • Definitions • Background, Motivations • Authentication Options • Authorization Options • Futures © Copyright 2004 CoreStreet, Ltd. Terminology Authentication Authorization (AuthN) (AuthZ) “Who are you?” “Are you currently allowed to access this?” Authentication factors • Something you have: • More time sensitive – Physical badge/token process – Secret/private key • Something you are: – Finger / eye / voice / etc. • Something you know: – Password – PIN © Copyright 2004 CoreStreet, Ltd. Access Control Circa 2004 • Authentication and Access Control System authorization require a “database” – networked or local ACL • Users, privileges, and Readers rules specified into database ID # • Frequently weak authentication Contactless Badge • No federation © Copyright 2004 CoreStreet, Ltd. Governments Issuing Common Cards • Homeland Security Presidential Directive – 12 – All government employees and contractors – Strongly resistant to identity fraud, tampering, counterfeiting – Can be rapidly authenticated electronically • FIPS PUB 201: Personal Identity Verification (PIV) – NIST, February 2005 – Contact + ISO 14443 contactless smart card – Three factors on card: digital certificates, PIN, biometrics • NIST SP 800-73: Interfaces for PIV – March 2005 • NIST SP 800-76: Biometrics for PIV – Draft • Japan: ISO 14443 PKI driver’s licenses in 2006 © Copyright 2004 CoreStreet, Ltd. Access Control Goals • Strong authentication – Without accessing a trusted database – Inter-organizational (federated) trust – Scalable to government sizes, locations • Flexible authorization – Securely determine current privileges – Support federated, offline use cases © Copyright 2004 CoreStreet, Ltd. AuthN: Card Serial Number “What’s your manufactured serial number?” “0x18a66e098b” PRO: CON: • Unique and unambiguous • No cryptographic or • Serial number of legitimate protocol protections card cannot be modified against spoofing Authentication Assurance: Basic © Copyright 2004 CoreStreet, Ltd. AuthN: Card Holder Unique ID (CHUID) “What’s your issued serial number?” JohnDoe-DoD-6128386 Digital signature PRO: CON: • Can include affiliation for • Can be cloned onto federated usage emulated card • Read-only on legitimate card • If signed, cannot be arbitrarily modified/created Authentication Assurance: Basic © Copyright 2004 CoreStreet, Ltd. AuthN: Symmetric Key on Card “Encrypted partial session key” “Encrypted partial session key” PRO: CON: • Strong anti-cloning • Master key distribution • Fast, cheap to implement problem on card • Steal master keys, clone any card • Impractical for federated usage, offline devices Authentication Assurance: High – small/closed environments © Copyright 2004 CoreStreet, Ltd. AuthN: Signed Biometric Templates “Give me your biometric templates” Format metadata Format metadata Format metadata Card serial number Card serial number Card serial number Biometric template 1 Biometric template 2 Biometric template 3 Finger 1 Finger 2 Face Digital signature Digital signature Digital signature PRO: CON: • Stronger anti-cloning than • Card storage capacity (e.g.) CHUID • Interoperability • Can include affiliation for • Forgery: can’t revoke federated usage biometrics • Privacy Authentication Assurance: Medium-High © Copyright 2004 CoreStreet, Ltd. AuthN: Signed Biometric References “Give me your biometric templates” Format metadata Biometric template 1 Finger 1 Card serial number Biometric template 2 Biometric hash 1 Finger 2 Biometric hash 2 Biometric hash 3 Biometric template 3 Digital signature Face PRO: CON: • Better storage • Interoperability • Stronger anti-cloning than • Forgery: can’t revoke (e.g.) CHUID biometrics • Can include affiliation for • Privacy federated usage Authentication Assurance: Medium-High © Copyright 2004 CoreStreet, Ltd. AuthN: Private Key on Card “Give me your cert” “Challenge: 12345678” “Response: 81a1bd099” PRO: CON: • Strong anti-cloning • Potentially higher cost per • None of the privacy card concerts of biometrics • Combo card vs. Dual • Optional part of NIST SP Interface: Cost vs. 800-73 (Card Security? authentication key) Authentication Assurance: High © Copyright 2004 CoreStreet, Ltd. AuthZ: Trusted Database • Requires transaction-time connectivity • Hard to scale • Hard to federate © Copyright 2004 CoreStreet, Ltd. Signed Status Assertions Status Assertion: 4/30/05 US DoD #909090909 Rumsfeld,  Employee Donald  Clearance: High  Not a Pilot ID #90909090909 Signed: Trusted Authority From: 2004JAN01 To: 2006DEC31 © Copyright 2004 CoreStreet, Ltd. AuthZ: Signed Status Assertions • E.g. Attribute Certificates, SAML Assertions Status / Privilege Assertion • Assertions of status (revocation) and/or privileges (attributes) • Using OCSP Responses due to size, PIV mandates for revocation checking • Don’t require trusted communications © Copyright 2004 CoreStreet, Ltd. AuthZ: Portable (Offline) Assertions • Synchronize to devices • Carry on the cards (aka sneaker-net) in standardized locations Authorization Application • Maintain local control of Authorization message file local privileges OCSP Response Cert ID: 1234 Status: Valid Expires: 1/7/05 17:00 Privileges: Medic Optional additional files … © Copyright 2004 CoreStreet, Ltd. Unify Assertions for Convergence • Converge Identity OCSP Response Management for physical and Cert ID: 1234 Status: Valid logical Expires: 1/7/05 17:00 Privileges: Medic • Use strong PKI methodologies in physical • One large-scale infrastructure for privileges instead of two © Copyright 2004 CoreStreet, Ltd. The Future • Short-term US PIV cards: – high assurance logical access AuthN – low assurance physical access AuthN • Contactless PKI available today, adoption as price per card decreases • PKI methodology creeping into physical access control • Embedded systems (locks, cards) can have reasonable horsepower © Copyright 2004 CoreStreet, Ltd. Progress in hashing cryptanalysis Arjen K. Lenstra1,2 joint work with Benne de Weger2 1 Lucent Technologies’ Bell Laboratories 2 Technische Universiteit Eindhoven Outline • Brief summary of cryptographic hash functions: • purpose, design criteria, iterative design approach • popular hash functions • Cryptanalysis until August 2004 • Dobbertin, Dean et al. • Recent cryptanalytic developments • random collisions (Wang et al.) • cascading iterative hashes (Joux, etc.) • The possibility of undesirable constructions • Conclusion • what’s next? • how to respond? Brief summary of cryptographic hash functions • purpose: fixed-size ‘fingerprint’ for message integrity applications • design criteria for L-bit hash function H: • H must be quickly computable • given L-bit y, finding x with H(x) = y should take effort  2L (i.e., brute force): 1st pre-image resistant • given x, finding x  x’ with H(x) = H(x’) should also take  2L (i.e., same brute force): 2nd pre-image resistant • grey area • finding random x, x’ with x  x’ and H(x) = H(x’) should take effort  2L/2: random collision resistant (can’t achieve better than this due to birthday paradox) • outputs indistinguishable from ‘random’: random oracle Brief summary of cryptographic hash functions • purpose: fixed-size ‘fingerprint’ for message integrity applications • design criteria for L-bit hash function H: • H must be quickly computable • given L-bit y, finding x with H(x) = y should take effort  2L (i.e., brute force): 1st pre-image resistant • given x, finding x  x’ with H(x) = H(x’) should also take  2L (i.e., same brute force): 2nd pre-image resistant • finding not-entirely-random collisions should be hard too • finding random x, x’ with x  x’ and H(x) = H(x’) should take effort  2L/2: random collision resistant (can’t achieve better than this due to birthday paradox) • outputs indistinguishable from ‘random’: random oracle Iterative design of cryptographic hash functions Iterative L-bit hash function H: • Compression function f: maps pair (512-bit block, L-bit string) to L-bit string • Fixed L-bit string h0: initialization vector (IV) • Input x written as concatenation of 512-bit blocks: x1 || x2 || x3 || … || xm where xm contains padding and x’s length (MD-strengthening) • For i = 1, 2, …, m in succession, compute hi = f(xi,hi1) • Resulting Nice hash property: if H(x) of x equals f is collision final L-bit resistant, then string hm H is collision resistant But (2004): falling apart as soon as collisions can be found Popular cryptographic hash functions Most eggs in the Message Digest basket: • MD4, L = 128 • tweaked version: MD5, L = 128 • length extension: SHA-0, L = 160 • surprise tweak: SHA-1, L = 160 • more tweaks, more length extensions: SHA-224/256/384/512, L = 224/256/384/512 all in the same family, all iterative Hashing cryptanalysis until August 2004 • MD4 considered broken: Den Boer, Bosselaers, and Dobbertin, 1996, ‘meaningful’ collisions • MD5 considered weak: Dobbertin, 1996, collisions in the MD5 compression function • Iterated hash functions for which compression function fixed points can be found (i.e., all hashes in the SHA family): Drew Dean et al. (1999) found 2nd preimage weakness (hidden in Dean’s thesis, never published) • MD5 and up: security of practical applications not seriously questioned • Strong belief in effectiveness of tweaks Recent cryptanalytic developments in hashing • August 2004: • X. Wang et al.: actual random collisions in MD4 (‘no time’), MD5 in time  239, etc., for any IV • A. Joux: cascading of iterated L-bit and perfect M-bit hash does not result in L+M-bit hash – as commonly believed Last result particularly worrisome because of its simplicity Intermezzo: Joux’s result cascading of iterated L-bit and perfect M-bit hash does not result in L+M-bit hash: collisions much faster than in time 2(L+M)/2 find y11, y12 with f(y11,h0) = f(y12,h0) = h1 in time  2L/2 find y21, y22 with f(y21,h1) = f(y22,h1) = h2 in time  2L/2 … find yk1, yk2 with f(yk1,hk1) = f(yk2,hk1) = hk in time  2L/2 Then: y1u||y2v||…||ykw for all u, v, …, w  {1,2} all collide  2K- fold collision in time K2L/2 With K = M/2: for any M-bit hash function there will be a pair among the 2M/2-fold collision that collides for that M-bit hash as well  simultaneous collision for L-bit hash and M-bit hash in time (M/2)2L/2 + 2M/2, for iterated L-bit hash and any M-bit hash Recent cryptanalytic developments in hashing • August 2004: • X. Wang et al.: actual random collisions in MD4 (‘no time’), MD5 in time  239, etc., for any IV • A. Joux: cascading of iterated L-bit and perfect M-bit hash does not result in L+M-bit hash – as commonly believed • A. Joux: actual random collision for SHA-0 in time  251 • E. Biham: cryptanalysis of SHA-1 variants • October 2004, Kelsey/Schneier (based on Joux): 2nd preimage weakness in any iterated hash (improving Dean) February 7, 2005, NIST announcement: • recent developments have no effect on SHA-1 • phase out SHA-1 by 2010, purely based on ‘Moore’s law’ Recent cryptanalytic developments in hashing • August 2004: • X. Wang et al.: actual random collisions in MD4 (‘no time’), MD5 in time  239, etc., for any IV • A. Joux: cascading of iterated L-bit and perfect M-bit hash does not result in L+M-bit hash – as commonly believed • A. Joux: actual random collision for SHA-0 in time  251 • E. Biham: cryptanalysis of SHA-1 variants • October 2004, Kelsey/Schneier (based on Joux): 2nd preimage weakness in any iterated hash (improving Dean) • February 14, 2005, X. Wang et al. (based on Wang/Joux/Biham): • actual random collision for SHA-0 in time  239 • random collision possibility for SHA-1 in time  269 (or 266) (269 < 280 – no reaction or retraction from NIST yet) Long term prospects of Popular cryptographic hash functions Most eggs in the Message Digest basket: • MD4, L = 128 out, no news • tweaked version: MD5, L = 128 out, no news • length extension: SHA-0, L = 160(never in) • surprise tweak: SHA-1, L = 160 out, an unpleasant surprise • more tweaks, more length extensions: SHA-224/256/384/512, L = 224/256/384/512 ?? all in the same family, all iterative Even given the ‘substantial changes’ compared to SHA-1, to what extent can we still trust SHA-224/256/384/512? How do the Wang et al. collision attacks work? Interestingly: • people are still trying to figure it out • V. Klima succeeded: improved the MD5 attack to  233 Very roughly speaking: • differential paths of compression function f are analysed • find M0 and low Hamming weight 1,in and out such that f(M0,h0) = f(M0+ 1,in,h0) + out = h1 + out • MD4 is so weak that out = 0 for low Hamming weight 1,in  0 • find M1 and low Hamming weight 2,in such that f(M1,h1) = f(M1+ 2,in,h1 + out ) • as a result M0||M1 and M0+ 1,in||M1+ 2,in collide • for SHA-0, 1,in = 0 (and thus out = 0) to get ‘convenient’ h1, (later version omits M altogether: single block SHA-0 collision) The possibility of undesirable constructions Often repeated argument: • random collisions are not good for anything • all collisions so far are ‘random’, so we’re fine Despite this argument: • published random collisions used for actual attack examples involving integrity checks for downloadable files (Tripwire etc.) • random collisions combined with iterative structure suffice for interesting X.509 constructions • so far no truly ‘disastrous’ applications (imo) X.509 certificate X.509 allows following format of data that will be hashed and signed: p1|| m || p2 where: • p1 contains header, distinguished names, and header of public key part, may assume that p1 consists of whole number of blocks • m is an RSA modulus • p2 contains public exponent and all other data until signature part  For collision purposes, the obvious place to ‘hide’ random data would be the RSA modulus X.509 collision construction ingredients 1. if collisions can be found for any IV, then collisions can be concocted such that they have same prescribed initial blocks Identical stuff of one’s choice can be prepended to new collision 2. proper (and identical) data appended to random data pairs turns random pair plus appendix into pair of valid RSA moduli Random collision can be promoted to meaningful data 3. arbitrarily selected data can be appended to colliding messages of same length, and they will still collide Identical stuff of one’s choice can be appended to any collision 1 & 3: due to iterative nature of hashes 2: a new trick for RSA moduli construction X.509 construction details Construct colliding p1|| m || p2 and p1|| m’ || p2 as follows: 1. Prepend: • pick properly formatted p1 with names etc., whole # blocks • compute p1’s intermediate hash value h • ask X. Wang to find random collision m1, m2 with h as IV • p1||m1 and p1||m2 now collide as well 2. Promote: • find m3 s.t. m1||m3 = m and m2||m3 = m’ are RSA moduli • random m1, m2 extended to meaningful m1||m3 and m2||m3 3. Append: • p1||m1||m3 = p1|| m and p1||m2||m3 = p1|| m’ still collide • and so do p1|| m ||p2 and p1|| m’ ||p2 for any p2 Applications of X.509 colliding certificates? • Can get one certificate for the price of two • Sign using one certificate, later deny based on other certificate • Keys involved must have been generated simultaneously, so detection of this fraud attempt is easy • No other attack scenarios that are facilitated by these types of collisions (see www.win.tue.nl/~bdeweger/CollidingCertificates) Outsider’s X.509 collision assessment • CA can no longer establish proof of possession of private key • Does not seem to lead to dangerous attack scenarios (we refer to it as a ‘construction’, not an ‘attack’) Insider’s point of view may be different • Greater danger if m and m’ could be made to contain different ‘subject distinguished name’ information • This may be possible if ‘grey area’ is exploited • Stay tuned –seems more is possible than we thought Problems can be avoided by making sure that: no one can predict any prefix of the hashed & signed part before hashing and signing take place (this is not part of the X.509 specs) RSA moduli construction The problem: for any m1 and m2 of same length N, find m3 such that m1||m3 and m2||m3 are secure RSA moduli The solution (for ‘any’ M > 0): • repeatedly pick two M/2-bit primes p and q • use Chinese remaindering to find M-bit m3 such that p divides m1||m3 and q divides m2||m3 • until (m1||m3)/p and (m2||m3)/q are both prime N = 1024, M = 1024, 2048-bit moduli, 512-bit smallest factors: secure N = 512, M = 512, 1024-bit moduli, 256-bit smallest factors: not secure Other strange RSA moduli Variants of our new RSA moduli construction allow: • ‘Twin RSA’: RSA moduli (n, n+2), with factors of same size • ‘predetermined Twin RSA’: RSA moduli (n, n+2) with fixed leading half bits, and factors of different sizes Predetermined Twin RSA, 2048-bit example n = 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 396099A3 5F9D2B49 E7BB729E 9542A7B0 A1FAD34B EE884199 E29A5DB4 E49DE1C8 279682F4 2A92FBFF 4F0F891F 65638997 B28D26DA 10B7529A 40CFA534 8BB95BE8 ADF4A21B 7DC562D4 93590D53 6B6124C5 6DB5D693 1004A7B4 C031C401 A4B6E1E8 EA5C8362 E7B2DB3F BFDEF87D 75311FEA 7D9BF1C3 9E3E64DF 9163E468 6D5D2711 and n+2 are secure RSA moduli, with independent factorizations  two 2048-bit RSA moduli for just 1024 bits Other strange RSA moduli Variants of our new RSA moduli construction allow: • ‘Twin RSA’: RSA moduli (n, n+2), with factors of same size • ‘predetermined Twin RSA’: RSA moduli (n, n+2) with fixed leading half bits, and factors of different sizes • These moduli look highly suspicious Questions: • Can anyone break them? • Can anyone break n given factorization of n+2 (or vice versa)? • Good for what? (One to sign, other to encrypt? Backup key?) Conclusion What’s next? • Continued improvements of random collision attacks very likely • Exploitation of ‘grey area’ looks promising • More ‘interesting’ constructions may emerge How to respond? • short term: case by case risk analysis, in most cases no need for changes, migrate in high risk cases only (to what? SHA-256?) • long term: • hard to defend long term application of SHA family • also hard to defend application of SHA-1 until 2010 • current iterated approach has undesirable properties • what about AES-like competition for AHS, ‘Advanced Hash Standard’? Identity-Based Encryption with Conventional Public-Key Infrastructure Jon Callas PGP Corporation Palo Alto, California, USA jon@pgp.com 18th February 2005 Abstract This paper proposes an identity-based encryption (IBE) scheme based on traditional public-key cryptographic systems, such as RSA, DSA, Elgamal, etc. This scheme has a number of advantages over other systems. It can rely upon these traditional systems for its security. Since it uses these traditional encryption schemes, it is interoperable with and easily embedded within an existing security system that uses these functions. Additionally, its construction as an on-line system avoids the operational security flaws of IBE systems that allow off-line key generation. 1 Introduction Conceptually, public keys behave a lot like telephone numbers — if I want to call you, I need your telephone number. I don’t need my own number to make calls (I can use a pay phone, for example), I need one to receive them. In a fashion that is analogous to a telephone number, I need your public key to encrypt something so that it is secret to you. Unlike telephone numbers, public keys are far too big for people to remember. Even elliptic curve keys, which are much shorter than the traditional ones are far too large for a person to remember. George Miller’s classic research [MILLER56] done on telephone numbers is that the average person can remember seven give or take two digits. A 160-bit key will be something over 40 digits long (exactly 40 if we use hexadecimal). So memorizing someone’s key the way you memorize their phone number is completely out of the question. Consequently, we need to have some blobs of data that say that a name such as alice@example.com belongs to some key. There is also value in digitally signing the blob so that the receiver has some assurance that the association is accurate. These blobs are certificates. Like any data management problem, certificate management is harder than people would like. This is why in 1984 Adi Shamir suggested the idea of coming up with a crypto scheme in which any string can be a public key [SHAMIR84]. Thus, there is no need to associate a name with a public key, because they’re effectively the same. This is Identity-Based Encryption. 1 While typically we think of IBE systems converting names into public keys, it should be possible to make any arbitrary bit-string, ID ∈ {0, 1}∗, a determinant of a public key in an IBE system. Thus, a name, an email address, or even a binary object such as a picture or sound can be considered equivalent to a public key. Thus, an IBE system can be thought of as a function of the form Ki = IBE(IDi ) that produces keys from arbitrary bit strings that we call identities, without loss of generality. 2 Overview IBE can also be thought of as an Attribute-Based Enrollment mechanism. Its goal is to reduce the overhead required to bring an entity into the system. Thus, we take some attribute of the entity and use that as a functional equivalent to a public key. In the past, work on IBE has been mathematical. It has developed a new public-key cryptosystem that has as a part of its key creation some arbitrary bitstring that is the identity. We examine this past work and look at how they are put together, as well as the limitations on these previous systems. Next, we construct a framework for an IBE system that satisfies the basic goals of IBE — that this attribute of an entity, its so-called identity is equivalent to a public key — and uses a parallel structure. However, this new framework can construct key pairs that are of a familiar cryptosystem such as RSA, rather than requiring its users to adopt a new public key algorithm. This construction also differs from present IBE systems in that it does not allow off-line generation of keys, but we also note that off-line generation has security drawbacks as well as advantages. However, on-line generation also permits a hybrid PKI that has both traditional and identity-based aspects in the same infrastructure. Lastly, we look at open and unsolved problems that surround IBE systems in general, including this one. All IBE systems created so far have a set of limitations as well as characteristics that are not yet solved. They do not remove the utility or desirability of IBE, but do limit where it can be effectively deployed. 3 Components of IBE An IBE system contains four basic components in its construction: 1. System Setup: IBE systems rely upon a trusted central authority that manages the parameters with which keys are created. This authority is called the Private Key Generator or PKG. The PKG creates its parameters, including a master secret Kpkg from which private keys are created. 2. Encryption: When Bob wishes to encrypt a message to Alice, he encrypts the message to her by computing or obtaining the public key, PAlice , and then encrypting a plaintext message M with PAlice to obtain ciphertext C. 2 3. Key Extraction: When Alice wishes to decrypt the message C that was encrypted to her name, she authenticates herself to the PKG and obtains the secret key SAlice that she uses to decrypt messages. 4. Decryption: When Alice has C and SAlice , she decrypts C to obtain the plaintext message M. No matter the specific parameters or requirements of the system, these functional aspects are always present in IBE systems as their defining components. 4 Previous Work Shamir’s original system was based upon RSA encryption and is a signature-only system. Shamir was unable to extend it to an encryption system. Between 1984 and 2001, a number of IBE systems were created, but they all had limitations, such as requiring that users of the system not collude, or requiring large amounts of computation on the part of the PKG. In 2001, two new proposals were published, improving on previous work. Clifford Cocks created a scheme based upon quadratic residues [COCKS01]. Cocks’s system encrypts bit-by-bit, and requires expansion of the message; for a 1024-bit modulus and a 128-bit bulk encryption key, 16K of data must be transfered. With modern networks, this is a completely acceptable overhead1 . Dan Boneh and Matt Franklin created a scheme based upon Weil Pairings [BF01]. Pairing-based systems use bilinear maps between groups to establish a relationship whereby hashes of the identity create the encryption scheme. Boneh-Franklin IBE has had further work [BB04] and is an active area of research. Horwitz and Lynn [HL02], Gentry and Silverberg [GS02] improved upon performance characteristics of a Boneh-Franklin PKG by extending IBE systems to Hierarchical IBE (HIBE). Their work is important particularly because of its attention to the practical details of constructing a scalable PKG. Gentry also described Certificate-Based Encryption (CBE) that uses an IBE system with certificates to create a hybrid approach [GENTRY03] that essentially makes the “identity” not be a name, but a well-defined certificate. In a conceptually related approach, Al-Riyami and Paterson have their Certificateless Public Key Cryptography [AY03]. Benoît Libert and Jean-Jacques Quisquater also created an identity-based signcryption scheme based on pairings [LQ03]. These signcryption schemes combine both aspects into one operation. There is other somewhat related work on combining signing and encryption as well such as [ZHENG97]. 1 Other discussions of IBE have characterized this expansion as an unacceptable overhead. Debating how much expansion is tolerable is orthogonal to this paper, but I feel it necessary to explicitly state that I find acceptable what previous authors find unacceptable. Networks continually get faster. Many messages are small enough that other overhead they already have to deal with (like conversion to HTML) also expand them. In the case where the message is large, clever software engineering could use compression and efficient bulk encryption to make this no worse than other message bloat. 3 5 Limitations on Previous Work All of the existing IBE systems have their own limitations. Shamir’s system signed but did not encrypt. Cocks’s system needs care to avoid an adaptive chosen ciphertext attack. It is also inefficient, but still efficient enough for use on reasonable communications paths. While others have proofs of security, there is a notoriously poor relationship between proofs of security and actual system security. Security proofs can show where a system is safe, but not protect against new assumptions that an adversary can bring to bear against the system nor against uses of a system that its creators did not think of which may be outside of the scope of the original threat model. Still other subtle problems have shown up on other systems, such as the ability in early HIBE systems for colluding users to determine the PKG’s master key. With the exception of Shamir’s system, IBE systems rely on new public-key cryptosystems, most often Weil pairing. Consequently, they are not compatible with existing systems that use RSA, Elgamal, or DSA. This limits their practical application, since there are many existing systems built upon these cryptosystems. Also, experience and comfort with the security of these established systems is high. A key advantage that Shamir’s system has over all those that follow it is that it was based on established public key cryptography, and thus (had it been successful in being both a signing and encrypting system) interoperable with non-IBE systems. Had Shamir’s system been successful at encrypting, an RSA-based IBE system would likely be the dominant IBE system today, if for no other reason than its interoperability with deployed systems. This is an important observation — if we can construct an IBE system that uses traditional, integer-based, public key cryptography, the barriers to adoption of IBE systems might be lowered. The value that IBE has can be fully realized if it can be made to work with these established systems. Furthermore, this system has the advantage that it can rely on twenty years of mathematical and operational familiarity with these traditional public-key cryptosystems. 6 Security Parameters of the Off-Line and On-Line worlds Previous IBE systems have as a desirable property that they support off-line generation of keys. That is to say, Bob receives key-generation parameters from the PKG once, and then can generate an arbitrary number of public keys. While off-line key generation is desirable, it is not without its own security consequences. 6.1 Advantages of Off-Line Generation Off-line generation is ideal in an off-line environment. If communication with the PKG is slow, expensive, or unreliable, then off-line generation is a huge advantage to its users. They need only one interaction with a given PKG to be able to do all needed work with that server. This advantage becomes less, however, as communication with a PKG becomes cheaper, easier, and faster. One some level, off-line key generation is nothing more than a key server that is an algorithm instead of a database. This is an advantage when databases are static and expensive, but not when databases are cheap and fast. In an environment where the contents of the database 4 are dynamically changing, a database change is not only an algorithm change, but an algorithm change that must be propagated to all clients of the PKG. 6.2 Disadvantages of Off-Line Generation Oftentimes, the strengths of a system are also its weaknesses. This is also true with off-line generation. Off-line generation makes key generation easy not only for legitimate users of of the system but for illegitimate ones. An issue that PKIs must consider in their design is that of a Directory Harvest Attack, in which senders of unwanted advertisements or outright fraudulent confidence games use the directory as a way to discover information paths into the system. Off-line generation of keys allows spammers and other attackers to to pre-generate email attacks in their own system or create a distributed system for encrypted attacks. These attacks are not an issue in off-line systems. Off-line generation has the disadvantage that there is complete transparency in the directory, since the directory is an algorithm. Anyone with that algorithm has all possible entries in the directory and their public keys, and this can be exploited in side-channel attacks that are not attacks on the cryptographic system per se, but the way the system is used. Off-line generation has as an additional disadvantage increased revocation problems. A conventional PKI must be able to re-issue certificates and handle for revisions in the PKI. An off-line IBE system must not only handle revocation of the certificates themselves but a revocation of the algorithmic parameters that comprise its own PKI. No IBE system before this one has even considered this real-world problem. In fact, the key advantages of this on-line system are that it considers and solves these real-world problems. 6.3 On-Line IBE for the On-Line World Sadly, trends in the real world make the advantages of off-line IBE moot, and turns its disadvantages into outright security problems. There is little need for off-line generation in an on-line world, and the advantages of off-line generation benefit attackers more than defenders. Nonetheless, IBE has desirable characteristics. The core IBE concept, that there is an equivalence relationship between bit-strings and keys has appeal. Designing an IBE system that has the advantages of name-to-key mapping without the security flaws of off-line key generation can make IBE acceptable to the complex security requirements of the Internet. Furthermore, if we shift the IBE system to an on-line system, we can construct it so that it uses traditional keys. This permits an IBE system to be embedded within an existing cryptosystem and interoperable with existing systems that use these keys. Not only does this remove adoption issues, but it also simplifies proofs of security; it is trivial to prove that an encryption portion of an IBE system is as secure as RSA if the underlying encryption is RSA. Another advantage is that an on-line system can normalize the identity. It is common for users of an email system to have equivalent identities on the system. For example alice@example.com 5 and asmith@example.com may be the same user, and it is desirable to have only one key. An on-line system can canonicalize identities at runtime. Finally, and perhaps counterintuituvely, this permits IBE keys to be used in certificates. We usually think of IBE as a way to eliminate certificates. However, all keys require standard data structures for transport. Whatever flaws they have, certificates are existing, standard ways to format key material in a way that systems can reliably use them. Objections to certificate-based systems are not objections to the certificates per se, but to the certification process. Without a standard set of transport data structures, IBE proponents must standardize on key transport data structures and convince developers to use those structures as well as the new crypto algorithms and protocols. Using existing certificate systems reduces the Key Extraction problem to an existing problem that has a simple solution, e.g. a lookup in a directory. Combining certificates with IBE is not new to this proposal. Gentry’s CBE combines a form of certificates with Weil pairings. On-line systems are ubiquitous and becoming more available every day. Consequently, the advantage of off-line key generation in an IBE system not only has less value today than it did when Shamir first suggested IBE in 1984, but new attacks turn it into a boon for the attacker of a system. Relaxing the parameters of an IBE system so that Bob is required to ask the PKG for each key is certainly practical, and permits us to exploit these other desirable system features. 7 Constructing IBE to Use Conventional Cryptography It is a goal of this system to describe how to construct an IBE from well-known components that have easily-understood security constraints, including proofs of security. Thus, what follows is actually a adaptive framework for constructing an IBE system that is not bound to a single algorithm and is functional even in the face of security advances such as new attacks on hash functions [BIHAMCHEN04] [JOUX04] [WANG04]. 7.1 System Setup Setting up the PKG consists of the following steps: 1. The PKG selects a master key, Kpkg . This key must be selected with care, as the security of the underlying system can be no more than the security inherent in this key. This key may be a symmetric key, or an asymmetric key. 2. The PKG selects an Identity Digest Function, IDF. This is a pseudo-random bit function of the identity, ID, and Kpkg that gives an Identity Digest Token, IDT such that IDT = IDF(Kpkg , ID). The IDF can be a symmetric-cryptographic function using the Kpkg as some simple secret. For example, it could be a an HMAC, a CBC-MAC, or some other suitable pseudo-random bit function. The IDF may also be an asymmetric-cryptographic function such as RSA, in which case Kpkg might be an appropriately strong RSA key and IDT is thus the result of an 6 RSA encryption of either ID directly or a hash of ID. Note that in this and similar cases, padding must be considered carefully to preserve the needed determinism of the IDF as it establishes a one-to-one correspondence between ID and IDT. Without a one-to-one correspondence, then this is not an IBE system at all. It may be desirable for this selection to be part of the setup; the PKG could be built with a number of options of IDF, one selected at setup time. Regardless of IDF selection, the resultant IDT is a limitation on the security of the IBE keys. If, for example, it were the CBC-MAC of a block cipher with a 64-bit block, then the underlying system has a birthday attack on the IDT that is probably less than the other parameters of the system. Selecting the IDF requires analysis of the overall system lest this be the security bottleneck of the system. 3. The PKG selects a deterministic pseudo-random number generator, RN G that will be seeded with IDT. This RN G is not the same function as IDF as it will in turn be used by a key generation function, Kgen, that generates an IBE key pair. This would be an RSA, DSA, Elgamal, or other key generation function2 . Of course, it itself must be deterministic, as the same key must be generated any time a given identity is put into the system. This construction has advantages beyond the simplicity of being able to use any key type within an IBE system. The security of the system relies on previously-studied components, which provides for easier security analysis. It also implicitly guards against some forms of attacks, such as collusion attacks. Breaking the Kpkg is as hard as breaking known forms of cryptography. So long as a suitable IDF function is selected, the whole Kgen process is as secure as its underlying cryptographic subsystems. 7.2 Key Extraction When the PKG is requested for a key for a given ID, it follows the following process: 1. The PKG produces an IDT, such that IDT = IDF(Kpkg , ID). 2. The PKG seeds RN G with IDT. 3. The PKG generates a key with Kgen(RN G) to produce the appropriate IBE key pair, IKPID . 4. If the PKG has an unauthenticated request for the given ID, then it responds with IKPIDpublic . This happens when Bob asks for Alice’s key. 5. If the PKG has an authenticated request for ID, such as when Alice asks for her own key, then the PKG responds with both IKPIDpublic and IKPIDprivate . At this point, Alice and Bob each have the appropriate piece(s) of a conventional key pair and they use it normally. 2 Without loss of generality, the Kgen function can also be a function such as an elliptic-curve key generator. However, since one of the advantages of this design is that it produces keys that are usable within widely-used systems. When elliptic-curve systems are more widely used, it will be trivial to extend this to an IBE system based on them. 7 7.3 Encryption and Decryption Encryption and decryption are trivial; they are simply the encryption and decryption functions of the base cryptosystem of the IBE keys. Note that if the cryptosystem is a signature-based cryptosystem such as DSA, it is signing and verification rather than encryption and decryption. 8 Security Limitations As with all IBE systems, there are a number of security limitations of this system. However, in all cases the limitations of this system are no different than for other IBE systems. 8.1 Key Escrow Problem IBE systems are effectively key escrow systems. It is a limitation, if not an outright flaw of IBE that the PKG holds all the parameters needed to generate any key pair, if not the key pair itself. Consequently, Bob can never be completely assured that Alice and only Alice can decrypt a message or created a signature. In the real world this is less of a problem than it is in theory, as the security Alice’s secret key is always bounded by the operational parameters of her key storage. It is undeniable, however, that an RSA key generated on a secure token is going to be more secure than one generated in a PKG. IBE systems, including this one, may be unacceptable for some uses. If there is a legal requirement that Alice’s private half of her signing key be in her possession alone, then no IBE signing system will be acceptable. Boneh and Franklin suggest a partial solution to this problem. In their partial solution, their master key can be split using a secret-sharing system [SHAMIR79]. This has the advantage that no single entity has any of the core secret parameters. An adversary would have to compromise enough members of a set of PKGs to reconstitute the secret. Nonetheless, this is only a partial solution. At some point, the set of PKGs must reconstitute the parameters, and an adversary that sufficiently compromises the appropriate member can still get the parameters. Furthermore, since the members of the PKG set are likely to be close to identical, they are not independent in their security. If an adversary can compromise one member of the set, it is more possible if not likely that the adversary can compromise the whole set. Another solution would be to keep the master parameters in secure hardware, or even secret-shared across a set of pieces of secure hardware. But this adds complexity on top of complexity to the system. In this system, we accept that the IBE parts of this system are by necessity a key escrow system, but note that it can fully interoperate with another other PKI that is not a key escrow system. Furthermore, this system can be integrated with a more secure public key system to provide it with IBE features. For example, the IBE in this system gives a way that keys can be created for roles such as Security Officer or Ombudsman without pre-defining these roles or their owners prior to use. This is another advantage to merging IBE aspects into conventional PKI. Within a given 8 PKI, you can have parts of it that are IBE-derived, and parts that are fully-secure, edge-generated public key pairs. Moreover, they all interoperate seamlessly. 8.2 Security of Key Generation The security of the keys generated by the PKG are bounded by the selection of the underlying functions as well as the scale of the PKG. If the PKG is to generate many, many keys, then factors such as the possibility of identity collision have to be taken into account as well. This is not an intractable problem — there are many underlying functions that can be used for components of the PKG that have adequate security parameters for security. It must simply be noted that these are security design factors that are unique to an IBE system. 8.3 Security of Key Extraction When Alice extracts her private key from the PKG, the PKG must deliver it to her securely. There are many ways to do this, including secure network connections such as TLS [TLS]. It also must be packaged securely (and this is another place where existing data structure systems such as certificate standards gain help). This is again, not precisely a security problem but more of where the PKG builders must take care in their delivery system. 9 Open Problems IBE is not yet a mature discipline. There are a number of open problems beyond improving the security of the underlying system that are yet to be solved. Here is a short discussion of some of them. 9.1 Removing Key Escrow All IBE systems, including this one, accept the fact that they are key escrow systems. However, nearly any discussion of IBE includes a class of people who consider the escrow aspect to be a severe flaw. It certainly makes the system brittle, as security of the system relies on non-mathematical security. A real-world PKG must be an un-hackable computer, even if that computer has advanced mathematical techniques such as secret-sharing as an additional bit of armor. It makes the simplicity that IBE gives on one axis be balanced by complexity on another. As cryptographers and systems designers, we have accepted key escrow as a part of the playing field because if we don’t, there’s no IBE. In an academic paper, this is a reasonable assumption, but in the larger world, this assuming key escrow as an implicit part of the system cannot be simply brushed away. This is a large open problem with no good solution. IBE exists for operational simplicity, but has operational complexity as a cost. Removing that cost should be the primary goal of future work, in this author’s opinion. 9 9.2 Is it Possible to Eliminate Certificates? The whole raison d’être for IBE is to “solve” the certificate problem. However, this means that IBE assumes that it is possible for a certificate to consist solely of a name and a key. In the real workd, certificates have always been more than a mere binding between a name and a key; they also carry metadata about the name, the key, parameters of use, and even metadata about the metadata. One of the most important bits of metadata about a key is revocation data. If a name is a key, then it is not possible to revoke the key without revoking the name as well. The utility of Alice not having to have a certificate is small if she must revoke her email address if she loses a smart card. Furthermore, telling everyone who has Alice’s email address that they must use her new one (and thus new key) is precisely a key revocation problem with added disadvantages for Alice. Boneh and Franklin [BF01] suggest a clever solution to this situation. In their paper, they suggest that IDAlice not be "alice@hotmail.com" but "alice@hotmail.com || 2004". They even suggest that the PKG can create daily-use keys such as "alice@hotmail.com || February 29, 2004". As elegant as this solution is, it prompts other questions. Once an identity is not simply a name, but is now a name and a date, is it still Identity-Based Encryption? Phrased another way, isn’t "alice@hotmail.com || 2004" merely a different way to code a certificate? Implementing this solution also requires other surrounding standardization that detracts from the essential simplicity of the IBE concept. At this simplest form, you have to standardize on what a date is. This isn’t difficult, but you have to do it. You must also translate malformed dates (perhaps "2 Février 2004" into "02/02/2004:12:00:00.00UTC+0100" which again detracts from the simplicity of IBE, as this is no longer something that a human being can reliably type the way that they can reliably type "alice@hotmail.com". However, this is a problem that can be solve through software, an one where an on-line system has an advantage as it can canonicalize time in a central place, or even round to an internal epoch. Previously in this paper, we discussed the algorithmic revocation problem as well. No IBE system before this one has even considered how the IBE parameters, the IBE algorithm itself, can be revoked. The fact that IBE is brittle in its reliance on central secrets makes this lack a larger open problem. Lastly, there is no means in an identity to express variables within a cryptosystem. There can be no negotiation about acceptable block ciphers, data compression, data MACing, both start and stop date of a given key, and so on. An IBE system cannot help but be a one-size-fits-all system for these parameters. This may not be bad, it may actually be a simplifying assumption. However, expressing these concepts are part of why we have certificates despite the problems in managing them. There are two possible approaches to dealing with this paradox — one being to make an IBE system that codes a more formal certificate and then uses that as an IBE key, such as Gentry’s CBE, or this approach which adapts IBE so that it can be used within a traditional certificate system. 10 9.3 Is it Possible to Prove Ownership of a String? When we describe how IBE works, we get to the Key Extraction phase and glibly say Alice authenticates herself to the PKG to get her private key. How? If Alice is already an authenticated user of the PKG, this isn’t very difficult. If it is to hotmail.com that Alice must prove ownership of alice@hotmail.com, this is an easy problem. If worst comes to worst, she has a password she can type in. If it is to brand-new-service.com that Alice must prove ownership of alice@hotmail.com, it is a bit more difficult, but hardly impossible. A simple, if low-security mechanism is for brand-new-service.com to send her an email with some authentication token that she delivers back to brand-new-service.com. For those who believe this insufficiently secure, there are other protocols that are easy to devise that are more secure. For example, Alice could generate an ephemeral RSA key pair, give brand-new-service.com the public key, and then deliver to brand-new-service.com the decrypted authentication token as before. While not perfect, it’s an improvement. Devising a protocol that is immune to man-in-the-middle attacks is left as an exercise to the reader. However, if Alice must prove the ownership of "Alice Jones", then we have a very difficult problem. Names are hard to express in a certificate system, and among the many criticisms of certificate systems the most basic objections concern the way they handle naming [ELLISON00]. If a name is a key, then a certificate is a key, and all the naming problems we have in certificates we have in names. Making names be keys exacerbates this problem. If the IBE system uses other bit strings such as photographs, music, etc. as keys, proof of ownership could be arbitrarily hard, both technically and legally. 9.4 Performance Bottlenecks IBE systems in general suffer from centralization on many fronts. Not only does centralization create security issues, but it also creates performance issues. The PKG may have to do large amounts of work, especially when the system uses many short-lived keys. In this system, the need for the PKG to generate keys makes more work for it. Furthermore, generating a key for some cryptosystems such as RSA require more computation than for others, such as DSA. One possible solution to this problem is HIBE. HIBE expresses the user’s identity as a composite of identities. For example, Alice’s identity would be the tuple (IDAlice , IDhotmail.com ) [GS02] [HL02]. While attractive from a performance viewpoint, it also blurs the conceptual simplicity of a name being a key. It also requires that the identities themselves have some structure in them that can form a hierarchy. HIBE also provides a partial solution to the escrow problem as no single server has the key for any hierarchical identity; an adversary must compromise more than one part of the hierarchy. Additionally, systems that secret-split in a set of authorities could potentially also use this as a way to distribute the computational workload of IBE over the set. Nonetheless, performance is another consideration that IBE systems must take into account, and this one more than most, since there is no off-line generation of keys. 11 10 Conclusion This presents hybrid system that combines Identity-Based features with a conventional public-key cryptosystem. Its advantages over the previous systems are that it provides interoperability with existing systems and by becoming an on-line system avoids the security problems associated with other IBE systems that permit off-line key generation. Consequently, this brings the advantages of an IBE system — that any bit string be equivalent to a public key, without the disadvantages of permitting an attacker complete knowledge of the PKG. It thus brings at this modest cost the advantages of IBE to conventional public key cryptosystems. 12 References [AY03] S. Al-Riyami and K. G. Paterson, Certificateless Public Key Cryptography, extended abstract in Proceedings of ASIACRYPT ’03, LNCS 2894, Springer-Verlag, 2003. Full paper available in the IARC eprint archives, . [BB04] D. Boneh and X. Boyen, Secure Identity Based Encryption Without Random Oracles, extended abstract in Proceedings of CRYPTO ’04, LNCS 3152, Springer-Verlag, 2004. Full paper available in the IACR eprint archives, . [BF01] D. Boneh and M. Franklin, Identity-Based Encryption from the Weil Pairing, Proceedings of CRYPTO ’01, LNCS 2139, pages 213-229, Springer-Verlag, 2001. [BIHAMCHEN04] E. Biham and R. Chen, Near-Collisions of SHA-0, Proceedings of CRYPTO ’04, LNCS 3152, Springer-Verlag, 2004. Also available in the IACR eprint archives, . [COCKS01] C. Cocks, An Identity Based Encryption Scheme Based on Quadratic Residues, Proceedings of the 8th IMA International Conference on Cryptography and Coding, LNCS 2260, pages 360-363, Springer-Verlag, 2001. [ELLISON00] C. Ellison, Naming and Certificates, Proceedings of the tenth conference on Computers, freedom and privacy: challenging the assumptions, ACM, . [GENTRY03] C. Gentry, Certificate-Based Encryption and the Certificate Revocation Problem, Proceedings of EUROCRYPT ’03, LNCS 2656, pages 272-293, Springer-Verlag 2003. Corrected version available as . [GS02] C. Gentry and A. Silverberg, Hierarchical ID-Based Cryptography, Proceedings of ASIACRYPT ’02, LNCS 2501, pages 548-566, Springer-Verlag 2002. Also available as . [HL02] J. Horwitz and B. Lynn, Toward Hierarchical Identity-Based Encryption, Proceedings of EUROCRYPT ’02, LNCS 2332, pages 466-481, Springer-Verlag 2002. [JOUX04] A. Joux, Multicollisions in Iterated Hash Functions, Proceedings of CRYPTO ’04, LNCS 3152, Springer-Verlag, 2004. [LQ03] B. Libert and J. Quisquater, New Identity Based Signcryption Schemes from Pairings, IEEE Information Theory Workshop, 2003. Also available as . 13 [LQ04] B. Libert and J. Quisquater, What Is Possible with Identity Based Cryptography for PKIs and What Still Must Be Improved, Proceedings of EUROPKI 2004, pages 57-70, Springer-Verlag 2004. [MILLER56] G. A. Miller, The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, The Psychological Review, 1956, vol. 63, pp. 81-97. Also available as . [SHAMIR79] A. Shamir, How to share a secret, Communications of the ACM, Volume 22, Issue 11 (November 1979), pages 612-613. [SHAMIR84] A. Shamir, Identity-based Cryptosystems and Signature Schemes, Proceedings of CRYPTO ’84, LNCS 196, pages 47-53, Springer-Verlag, 1984. [TLS] T. Dierks and C. Allen, The TLS Protocol Version 1.0, RFC2246 [WANG04] Xiaoyun Wang and Dengguo Feng and Xuejia Lai and Hongbo Yu, Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD, IACR eprint archive, . [ZHENG97] Y. Zheng, Digital Signcryption or to achieve cost(signature & encryption) « cost(signature)+cost(encryption), Proceedings of CRYPTO ’97, LNCS 1294, pages 165-179, Springer-Verlag, 1997. 14 Identity-Based Encryption with Conventional Public-Key Infrastructure Jon Callas PKI ‘05 April 2005 ©2005 PGP Corporation Identity-Based Encryption • First proposed by Adi Shamir in 1984 • Certificates are data structures that can be hard to manage • What if public keys could be a function of an identity? – An identity is an arbitrary bit string. – Could directly convert the string into a public key pair • Can this lower or eliminate the need for certificates? • At the very least, does this ease enrollment issues? © 2005 PGP Corporation 2 IBE Construction • IBE systems consist of four components: 1. System Setup • Private Key Generator (PKG) uses master secret to generate key pairs • Establishes all keygen parameters 2. Encryption 3. Key Extraction • Owner of identity (ID) authenticates to PKG to get private key of key pair 4. Decryption © 2005 PGP Corporation 3 Progress in IBE • Pairing-based and other systems provide mechanism for producing public key pairs from strings • This has renewed interest and research in IBE • However, – New IBE systems use their own public-key cryptosystems – Incompatible with existing systems • Requires new software • Requires new standards • Can we answer Shamir’s IBE question with a conventional PKI (using RSA, Elgamal, DSS, EC Discrete Logs, etc.)? © 2005 PGP Corporation 4 Issues with IBE • Requires a central server – Server holds a master key that all public key pairs are derived from – Thus, IBE systems are key escrow systems – Requires extra computer security on this server; one secret determines all keys – No worse than systems like Kerberos, but no better, either – Difficulties arise from the expectation that users may truly possess keys © 2005 PGP Corporation 5 Issues with IBE (cont’d_ • Naming issues become paramount – All PKIs have naming issues (Ellison, etc. have discussed) – Key management becomes name management • jon, jcallas, jon.callas, jon_callas, 䛞䜎䛰䛛䜙䚭Ⅺ, cto, cso – Misspellings are also keys • john, calls, callis, etc. – The John Wilson problem can be solved with appropriate qualifiers – Key management doesn’t go away, it becomes slightly different © 2005 PGP Corporation 6 Issues with IBE (cont’d) • Revocation is difficult – If a name is equivalent to a key, does revoking the key require revoking the name? – Solutions include appending qualifying information to the name • “jon@pgp.com || 20-Apr-2005” – Can lead to explosion of names and qualifiers – Still need to distribute updated information • Legal Complications – EU data signature laws require private keys to be held only in signer’s hand – Some believe this applies to encryption keys as well © 2005 PGP Corporation 7 On-Line and Off-Line Key Generation • An interesting feature of some IBE systems is off-line key generation – Client contacts the server, gets generation parameters, then can create keys • In an on-line world, off-line generation is nice but superfluous. • Off-line generation may be a security flaw – This is a directory harvest attack for all possible keys – Makes changing parameters more difficult – On-line access still needed for revocation – Makes agglomerating equivalent names impossible as it is distributed – Exacerbates naming issues and naming errors • Giving up off-line generation gives us flexibility in creating a system © 2005 PGP Corporation 8 Conventional IBE Keys • Architecture • Example implementation • Select Master Key • 512 bit HMAC key, 512 bit salt • Select Identity Digest Function • HMAC-SHA512(k, salt||id) • Seed PRNG with result of IDF • PGPsdk PRNG • Generate public key with PRNG • PGPsdk keygen functions for RSA • Wrap in appropriate data structures • OpenPGP certificate, X.509 cert, SPKI, etc. • Other selections possible for key components, depending on desired qualities of system, multiple systems can be used within a single domain © 2005 PGP Corporation 9 Is This Really IBE? • It satisfies Shamir’s question, but with software engineering, not mathematics. • It is an IBE keygen function • Also has been called Attribute Based Enrollment • It isn’t an IBE cryptosystem • Gives up interesting mathematical property of off-line key gen, which is operationally of mixed security © 2005 PGP Corporation 10 Advantages of this system • Interoperates with existing systems – These keys wrapped as X.509, OpenPGP can be used with any other cryptosystem • Can mix IBE and non-IBE components – Directory software can constrain name explosion – Can authenticate or limit discovery of public keys – Can work with existing revocation systems – Existing cryptosystems need not know they’re working with IBE – Can work within political / legal constraints on key handling © 2005 PGP Corporation 11 Advantages (cont’d) • Can rely on security strength of underlying components – HMAC has security proofs as pseudo-random function – Crypto strength relies on cryptosystem security proofs • Works with any existing public key cryptosystem – RSA, DSS, DH, EC, etc. – All that is needed is PRNG-seeded key generator • Allows speculative encryption before ownership is even known – This is the true need that IBE fills, replicable data sealing to a given identity © 2005 PGP Corporation 12 Unsolved Problems • Key Escrow – Existence of master secret is operationally most risky form of escrow – Secure hardware is the best, possibly only solution • Does this remove certificates? – If you’re going to append a qualifier to an identity, that’s a simple certificate – Could be mixed with lightweight cert systems like SPKI for interesting systems • Proving ownership of a name – Easy to do in some cases -- proving a user name to a RADIUS, Kerberos server – Hard to do in abstract – Proof of unique ownership may require unique naming © 2005 PGP Corporation 13 Summary • Software Engineering solution to Shamir’s IBE question – Security limitations and concerns are same as other IBE systems • Creates a function that uniquely, deterministically creates public key pairs from identities • Trades off interesting mathematical properties of other systems for interesting operational properties • Gives existing, well-used PKIs benefits of Identity-Based Enrollment • Does not require new software infrastructure • Hybrid approach suited to real-world political and legal constraints © 2005 PGP Corporation 14 Questions? © 2005 PGP Corporation 15 A PROXY-BASED APPROACH TO TAKE CRYPTOGRAPHY OUT OF THE BROWSERS FOR BETTER SECURITY AND USABILITY Marco Antônio Carnut (kiko@tempest.com.br) Evandro Curvelo Hora (evandro@tempest.com.br) Tempest Security Technologies Universidade Federal de Sergipe - DCCE/CCET ABSTRACT This paper describes the implementation of a multiplatform selective filtering/rewriting HTTP proxy that allows the PKI-related operations – such as digital certificate issuance, web form field signing and HTTPS client authentication – to be performed entirely outside the browser, even though the browser continues to be used for what it’s good at: rendering web pages. Implications such as better usability through improved user interfaces are discussed in light of a prototype implementation. 1 INTRODUCTION this feature. In IE, it can be implemented using The SSL/TLS protocols were originally designed to ActiveX or even Java (although that requires installing provide encrypted and authenticated channels for web CAPICOM, making the process less transparent), but servers and clients. Even today, they are almost they tend to be too cumbersome for large-scale exclusively used to authenticate servers, despite its deployment. support for client authentication. There are many This paper investigates an alternative way to provide reasons for that: in [4], it is shown that getting a client client certificate-based authentication and web form certificate – even a free an instantaneous one – is too signature, along necessary subsidiary services such as much of a hassle for the average user. Internet digital certificate issuance, by performing all the Explorer (IE), the most popular web browser, makes it cryptographic and user interface chores in a separate all too easy to store the certificate without a program: we use a selective cryptographic passphrase; besides, its client certificate-based logon filtering/rewriting HTTP proxy to implement all the window is confusing, showing expired and revoked PKI-related features, leaving to the browser only what certificates along with valid ones and it is outfitted it’s good at: rendering web pages. This approach has with a “remember password” checkbox that causes the the advantage that it works with any browser that passphrase to be stored unencrypted, invalidating supports proxies. much of the security the process might provide. Specifically, we wanted to make a general purpose The way failures are handled is also confusing: when utility for handling digital certificates that provided the server can’t validate the client certificate (either easy-to-use digital signature generation and because it couldn’t build a trusted certificate chain or verification functions; and that could be integrated the client certificate was found to be revoked), it with the web browser to allow web form signature and simply breaks the connection; there are no provisions client certificate authentication in HTTPS with a much to redirect the user to a nice page explaining what went better user interface and security features under our wrong and how to fix it. control. We also wanted this utility to be a testbed for All these usability problems cause enough user new HCI ideas applied to client-side (primarily, but rejection that webmasters find it simpler to use weaker not limited to, web-based) PKI applications. authentication schemes such as This paper focuses on the cryptographic, PKI and name+password+cookies. Although vulnerabilities protocol issues needed to “take crypto on our own have been discovered (and in some cases fixed) in hands” (as opposed to letting the browsers do it), while most browser’s crypto implementations, bad human- simultaneously striving to maintain backwards computer interface (HCI) is often appointed as a compatibility. Although we do make extensive use of serious hinderance to PKI adoption in general [14] and screenshots to illustrate some features and preliminary client-based authentication in particular [18]. user interface (UI) ideas we implemented – and There have been a few attempts to improve the user- sometimes we even indulge in describing some of its friendliness of client authentication, such as VeriSign’s details and user feedback we received –, an analysis of Personal Trust Agent [17] and RSADSI’s Keon the merits of our tool’s UI is beyond the scope of this WebPassport [16]. However, as they are both ActiveX paper, for it requires entirely different approaches and controls, they are Windows-only solutions and since techniques. What we want here is to show one possible they are activated after the SSL handshake, they have way it can be done. to resort to proprietary authentication schemes. Besides general familiarity with the Another great promise brought by public key X.509/PKIX/PKCS standards and PKIs in general, this cryptography is the use of digital signatures as a way text assumes the reader has considerable familiarity to detect tampering on digital documents. Some web with the HTTP [1] and HTTPS [2, 3] protocols. browsers can natively sign the contents of web form fields, but many – most notably IE – do not support HTTP HTTP proxy at Requests 3128/tcp Filter #1 Infrastructure Filters (version tag, chunked Filter #2 encoding, etc...) . . The Engager tells the HTTPS Engager . . dispatcher to use the same HTTPS . . proxy the browser is using Encryption HTTPS The engager changes the currently running Domain Filters Dispatcher browser instances’ Internet configuration to use Security features ourselves as proxy.. Web Form filters (web logon Signing Filter over HTTPS, form signing, etc) HTTPS-Capable The Engager configures the . . Server . . HTTP dispatcher . . to use the proxy server the browser was Filter #n previously using. HTTP Dispatcher Figure 1: Overall architecture of the client proxy, which runs in the same computer as the browser. The engager changes the browser’s proxy settings so that it uses our own local proxy. Before doing that, though, it detects which HTTP and HTTPS proxies the browser was using and configures our dispatchers to use them. This effectively puts us in the middle of the proxy chain. New HTTP requests originated by the browser will pass through our proxy, where our filters may act upon them. In fact, we have two filter chains, one for the outgoing requests and other for the incoming responses; some of them act upon the headers, other upon the bodies. Some features actually require several filters in cooperation to implement. If none of the filters actually consume the request (i.e., take it out of the chain), it reaches the default dispatcher in the end of the chain and it is sent as an HTTP request. The Encryption Domain filterset is a special set of filters that reroutes the requests that match certain criteria to be sent over as HTTPS. The HTTPS dispatcher makes use of the certificate store services (not shown in this picture) to validate the certificates and perform client authentication (with a friendly UI) if the site so requests. point to our own proxy described above, so that 2 OVERALL ARCHITECTURE we get to intercept all HTTP traffic initiated by Our tool, code-named Kapanga, is an executable the browsers. Engagers are described in detail in program that typically (although not necessarily) runs section 2.3 . in the same computer as the user’s web browser. A • Default Dispatcher: an embedded HTTP user schematic depiction of its overall architecture can be agent that sits at the end of the filter chain. It acts seen in Figure 1. A brief description of its major like a “default route” in a routing table: any components follows: requests that reach it are sent their destinations, • Certificate Store Manager (CSM): provides all either directly or via another next-hop proxy. It the underlying cryptographic services needed by also proxies any authorization requests (e.g., all the other components. It manages and provides Basic, Digest or NTLM authentication) that the access to all the cryptographic objects next-hop proxy may require, so the authentication (certificates, certificate revocation lists, private protocol is handled by the browser itself and any keys, signatures, etc) stored in various kinds of username+password dialog boxes that may be storage media (the local disk, removable storage required is also shown by the browser itself. Upon devices, crypto-capable devices such as smart receiving the results, it pipes them back to the cards, etc); provides access to cryptographic response filters, which also play crucial security algorithms and protocols. The CSM is detailed in roles. section 2.1 . • HTTPS dispatcher and the Encryption • Filtering HTTP Proxy Server: receives the Domain: similar to the default dispatcher, but requests from the browser and feeds them through tunneling the requests over TLS/SSL [2]. For the filter chain. If no filters consume the request, it performance reasons, it features support for is passed to the HTTP dispatcher nearly rehandshakes and session caching [3]. It relies unchanged. Filters may alter either the request heavily on CSM services for validating the before they’re sent to the dispatcher or the replies servers’ certificates and providing client berfore they’re sent back to the browser. These authentication if the server so requires. A request changes implement the program’s main features, is sent through this dispatcher if the host:port as it will be detailed further along. of the request is listed in a set called Encryption • Engagers: they are in charge of changing the Domain (this detour is actually accomplished by a HTTP proxy settings of all supported browsers to special filterset collectively known as the “Encryption Domain filters”). As with the default certificate made by the private key of a user to dispatcher, it may either send the request directly indicate that it trusts that certificate (typically a or use the CONNECT method to tunnel it over a root CA). This signature is detached – that is, it is next-hop proxy [5] if the engager has previously stored in a separate file in a file format of our told it so. It is also responsible for sending back own devising; we will have more to say about any authentication requests that the next-hop attestations in section 2.1.1. . proxy may require. • Chaining: after the certificates are loaded from 2.1 Certificate Store Manager the physical stores, the CSM tries to chain them. First, duplicates are discarded and certificates Underlying the whole program is the Certificate Store issued by the same CA are sorted by their Manager, providing crypto and PKI services to the notBefore fields and assembled as a doubly- other subsystems: linked list. The best current certificate is selected • Certificate, CRL and private key enumeration by applying two criteria: a) it is the one with the and caching: all those objects can live in one or most recent notBefore and b) it must be still more physical media. The local hard disk is called within validity (that is, with the current date/time the primary store location, bringing a minimal set before its notAfter field). If no certificate of certificates right from the installation satisfies both requirements, we settle for the one procedure. that satisfies only (a). The user may configure one or more secondary After that we build several indices for fast lookup: locations. Those are usually removable media, one keyed by the certificate’s SHA1 hash, other such as CD-ROMs, diskettes or USB flash by its Subject Key Identifier extension [7] and memory devices (“pen drives”). Every three another by subject DN. This last one has a seconds or so the certificate store manager checks peculiarity: only the best current certificates make to see if these devices are readable and, if so, to this index; the future and previous editions rescans them. This way, a user may have and use don’t get there. his/her certificates/keys in a removable storage medium during their entire lifetime1. We then chain the certificates in the usual way, using the recently computed indexes to speed up Crypto devices such as smartcards are also finding the issuer of each certificate in the store supported, although they are handled as special (matching SKI/AKI pairs, when available, and by cases because some objects (private keys, subject/issuer DNs as a last resort). We set the primarily) may not be exported and we may only parent pointer of each certificate to the issuer and operate on them via the device’s built-in record its the depth in the tree (the whole chaining cryptographic capabilities. algorithm uses a breadth-first search precisely to The resulting in-memory cache can be seen as a make that trivial). concatenation of all the contents of all of the CRLs are considered as an appendage to their devices. CRLs are handled as a special case – issuer certificates and are chained to them. Private since some of them tend to get very big, they are keys are also appendages and are linked to the deallocated from memory as soon as the CSM is certificates with the corresponding public key (the done using them in the trust calculations. private key format stores the public key as well, so Private keys are handled as special cases as well. this comparison is straightforward). When stored in crypto devices, the CSM directs • Trust Status Calculations: With all the all its crypto primitives to the device’s drivers to certificates and associated objects properly make use of its embedded functionality; chained, we start to verify their validitity periods, otherwise, they are loaded only when needed and signatures of its issuers, attestations, etc. It is the crypto primitives (signing/decryption) are interesting to notice that all trust calculations are directed to the software-based implementation. relative to the currently selected default ID, since Our certificate store has another type of object attestations depend on it. Thus, whenever the user called attestation signature or simply attestation. changes the default ID via the GUI, the whole It is a signature block on someone else’s trust statuses are recomputed. Section 2.1.2. describes each trust status in detail. The CSM has a few other utilities and services: 1 Some of our users like to call this “the poor man’s smartcard”. We • Public CSM Server: We coded a version of the try to tell them this is a particularly nasty misnomer – not only because certain media such as USB “pen drives” are actually more CSM in a web server that is offered as an expensive than smartcards (even including the cost of the reader), associated on-line service to the user and acts a but also because they lack the tamper-proofness and crypto public certificate/CRL repository. Over the years, capabilities of the latter. n o q s r p t Figure 2: The CSM trust calculation results as displayed in the GUI. Here we have a certificate store with (1) three unattested roots and (2) three attested, trusted roots. There is also an Intermediate CA (3) that cannot be trusted because it’s unchained, meaning that we lack its issuer root. All children of trustred roots are marked as indirectly trusted unless they’ve been revoked (4), their signatures don’t match (6), or it’s not within its validity period (7). The item marked in (5) is the current ID (aking to PGP’s “default key”). All trust calculations are relative to the attestations (detached signatures on root CAs) this ID has previously performed. we’ve been dumping on this server every CA removing from the user the possibility of doing things certificate we lay our hands on. Whenever a manually if he/she so wishes. certificate is unchained, the Kapanga may query the CSM server (either automatically due a 2.1.1. Attestations configuration option or manually through a pop- Attestations are signatures of a private key in someone up menu in the GUI) to see if it knows the missing else’s certificates as a means of informing Kapanga issuer. The external CSM may also return CRLs – that the owner of that private key trusts the signed it has a built in robot that tries to fetch CRLs of all certificate. They are akin to PGP’s key signatures or CAs it knows about from its distribution points. introductions, except that they are stored in a file • Automatic CRL Download: Just like the public separate from the certificate itself. online CSM server, the program’s internal CSM We originally implemented attestations only for Root has a similar feature – it automatically tries to CAs as a more secure means to tell the CSM that download the latest CRLs from the addresses particular CA is to be considered trusted. We were advertised in each CA certificate’s trying to avoid a simple vulnerability most browsers cRLDistributionPoints extension. It can have: it’s quite easy write a malicious executable that do so upon user request or automatically in the inserts a new fake root CA in their trusted certstore – background. In the automatic mode, the list of in IE’s case, it can be done in a few lines of code, since candidates URLs is rebuilt each four hours the root CAs are stored in the registry; for Mozilla- (configurable) and we try to downloads CRLs derived browser’s, it requires only slightly more effort, from them. In case of success, the whole trust since the root CAs are in a Berkeley-DB file. settings are recomputed and redisplayed. If some As we will see in the next section, Kapanga trusts root download fails, the next attempt time is subject to CAs only if they’re signed by the user’s key. We say an exponential backoff algorithm with a maximum that the only truly trusted certificate is the user’s own, period of one week. because he/she has the corresponding private key. All The overall effect we tried to achive is that the user the trust placed in the other certificates, even root doesn’t have to worry about the intricacies of certificates, stems from the user. Hopefully it also certificate management at all: he/she would only use makes the root insertion attack slightly harder, for it the program features, collecting certificates along the will require the attacker to induce the user to sign the way, and the CSM will do its best to ascertain its trust corresponding certificates. statuses and keep everything updated – without Figure 3: Manual Attestation Process. The user must sign the Root CA’s certificate with his/her private key. Only then this CA will be considered directly trusted. The UI was designed as a single- step dialog box presenting the most important certificate identifiers for manual checking against other trusted sources, instead of the unecessarily complex and sometimes scary multi-step wizards most browsers have. The text succintly explains that this must be an informed decision. In this screenshot, we see the program requesting the private key’s passphrase, which reinforces the sense of importance of this action. An always- enabled but impossible to disable check box reminds the user that passphrases are case- sensitive. Root CA attestations are also integrated with the certificate issuance/import dialogs, so users rarely come to this dialog to perform root attestations; it is more often used to attest certificates other than roots. While this does improve security, this may seem as an this status overrides the “Unchained” and “No extra complication: we require the user to have a path to trusted root” statuses described below. certificate and private key; Kapanga is nearly useless if • Directly Trusted: this means that this certificate the user doesn’t, since it will trust no one. After getting has been attested by the current user. In other a certificate, the user would need to perform a few words, there is a signature block on this certificate attestations. We tried to make this simple by correctly verified against the current user’s public integrating the attestation process with the certificate key as proof that the user gave his/her direct issuance/import processes: as shown in Figure 4, when consent that this certificate must be considered the user gets a new certificate, a few checkboxes cause trusted. If this a CA certificate, this causes all its root to be automatically attested, as well as all other child certificates to be considered indirectly roots this root trusts: root attestations on other roots are trusted. our bridge-CA mechanism. • Indirectly trusted: this means that the CSM has Later on, we generalized the attestation system: the verified that the signature of the issuer is valid and user now can sign any certificate he/she chooses. that the issuer is trusted (either directly or This effectively makes Kapanga’s trust system a cross- indirectly). breed between the X.509’s strictly hierarchical and • Not Within Validity: the certificate is not trusted PGP’s web-of-trust models. While we were inspired because the current date and time is after the value by and tried to follow RFC 3280’s certificate specified in the certificate’s notAfter field or validation rules, we can’t really say we follow them to before the value specified in the notBefore the letter because it ended up evolving in a different field. This status overrides all others (even the direction. Ultimately Trusted stauts): the CSM doesn’t even Other interesting analogies can be drawn with other bother checking anything else. public-key based systems: for instance, signing an • Unchained: the certificate cannot be considered unchained server certificate in Kapanga is akin to as trusted because it we don’t have its issuer. This adding a SSH server key to the status applies only to intermediate CAs and end- ~/.ssh/known_hosts file, except it’s harder to entities; it obviously can’t happen in Root CAs. spoof because of the signature. This status can override all the previous ones except the “Ultimately Trusted”. 2.1.2. Trust Statuses • Not Attested: this only happens to Root CAs. The The trust calculations assign one of the following certificate cannot be considered as trusted because statues for each certificate: we either have no valid attestation signature on • Ultimately Trusted: this means that we have the this root from the current user’s. private key corresponding to this certificate. Thus, • No path to trusted root: the certificate cannot be it is an identity we can assume. Those certificates considered as trusted either because the root of the are considered to be “the root above the Roots”, chain has not been attested (it is not directly the true starting point all trust stems from. As a trusted) or some of its issuers are unchained (the result, such certificates are considered trusted chain doesn’t go all the way up to a root CA). even if they’re not properly chained or if its chain doesn’t go all the way up to a trusted root; we say • Revoked: the certificate is not trusted because its certificate. The rest of this subsection describes serial number is listed in its CA’s Certificate some particularities of this process. Revocation List (CRL) and the CRL itself is valid. In the first step, the user enters his name and email The trust statuses for CRLs work a bit differently. A address, being also warned that the process requires CRL is considered valid if the signature of its CA being online or else the process will fail – this is unlike matches just fine, regardless of whether it is outdated PGP. The user is also asked to reconfigure his/her or not. If a given certificate is listed in some CRL, it is spam filters to prevent the CA notification messages flagged as revoked even if the CRL is not the freshest from being blocked. possible; the CRL checking engine tries to do the best After that, the wizard asks the CA whether the email with what it has. It is the responsibility of the address the user requested is already taken – that is, automatic CRL dowload feature to try to keep CRLs as whether the CA has in its database a valid certificate up-to-date as possible. issued for that email address. This is implemented by When the CRL checking engine is asked about sending the CA a request for a “Revocation whether a certificate is revoked or not, it returns an Reminder”. If the server responds with a “No valid answer consisting of three items: certificate associated with this email address” message, • Is_revoked: a tristate flag saying whether the we let the user proceed. Otherwise we inform that the certificate is revoked (true), or not (false) or if we user is going to receive an email with revocation can’t ascertain because we have no CRL for this instructions and ask him/her to follow it before coming CA (unknown). If this flag is unknown, the back to try to issue the certificate again. In this remaining two items describe below are situation, the “Next” button of the wizard is grayed undefined. out, making impossible to proceed. The next step is setting up the passphrase – historically • Is_outdated: it says whether the CRL used to the step users hate the most. This is constitutes a good compute the is_revoked status is outdated or not. opportunity to describe what kind of usability ideas • Reference date: if is_revoked is true, it returns we’ve been experimenting with, so we will detour the revocation time and date as taken from the from the “protocol nuts and bolts” approach we’ve CRL. Otherwise, it returns the CRL’s been adopting so far and make an aside about our UI lastUpdate field, meaning that we can be designs. certain that this certificate isn’t revoked only up to The philosophy is to try to steer the user to do the right the moment the CRL was issued. thing, both through education and trying to prevent unwittingly dangerous actions. However, it can’t be 2.1.3. Certificate Issuance, Import and Export frustrating either, so the restrictions must not be Another important service provided by the CSM is absolute; they have to be bypassable, although the user providing support for having new certificates issued must feel frowned upon when choosing the insecure through a Certificate Authority. From the point of view path. of the CSM itself, its just a matter of having an RSA As usual, we have two passphrase text entry boxes. By keypair generated and converting it to an Netscape defaut, they are set not to show the text being typed, SPKAC (Signed Public Key and Challenge, see [12]) replacing the characters by asterisks. Just like in PGP, format (a Certificate Signing Request would seem a however this is bypassable by unchecking a “Hide better choice, but the reason for that will become clear Typing” checkbox. This is needed because some poor further along). typist users take too many attempts to make the From the point of view of the user interface, there are content of the text boxes match that they become two very different implementations: frustrated and quit. But unlike in PGP, if they opt to do • The classic web-based style, in which the user this, they get a insistent blinking message warning directs his/her browser to the CA web page, fills them to make sure they aren’t being watched or some web forms and the browser activates the key filmed. generation procedure. Since this issuance system We also implemented a warning about Caps Lock is intrisically intertwined with the filter system, it being enabled, now common in many programs. will be described along with our discussion of the Also common is the passphrase quality meter. The HTTP filters in section 2.2 . metering algorithm tries to estimate the entropy in the • We also wanted to have a PGP-like wizard-based password roughly by making a weighted average of instantaneous key generation. To that end, we two criteria: the word entropy and the character implemented a specialized wizard that uses entropy. The former is exceedingly simple-minded: we FreeICP.ORG’s Entry-Level CA [4] to allow the assume that each word adds about 11 bits of entropy. user to get a free, instantaneous short-lived The latter is more complicated: we determine the bounding set of the characters of the passphrase in the ASCII code space and use it as an entropy per diceware passphrases are more secure than those character estimator. Then we multiply it by the number approaches seems to convince them. On the good side, of characters and divide it by the efficiency of a however, our rejection rate has been zero precisely customized run-length encoder. This has the effect of because we give the users the choice: they can simply yielding very low scores to regular sequences such as disable the quality meter and ignore the suggestion box “aaaa” and “12345”. The quality meter displays its altogether if they really want to. Over time, we see that score in a progress bar and with a scale categorizing users gradually start to explore the passphrase them as “simple”, “good” and “complex”. suggestion box and the number of good passphrases The reason we didn’t bother to be much more slowly increases. A quantitative characterization of scientific than that with the quality meter is that in our those intuitive perceptions may make fertile ground for early attempts it became clear it would result in it a future paper. being overly frustrating to the end users. Our priority The last page of the wizard is the one where the key is to keep the users happy (or at least not too unhappy), pair is generated. As many other implementations do, a so we calibrated (or rather downgraded) the algorithm progress bar tracks the possibly lengthy key generation many times to quell their complaints. We did perform process; we were working on an educational animation some research about it, but in the limited time we had to add to this window, but a discussion of its features we could find no real good papers with general design is beyond of the scope of this paper. guidelines for passphrase quality meters. We opted for After the key pair is generated, the private key is trial and error based on the users’ feedback. encrypted with the passphrase and saved in the In the end, we struck a middle ground with the Certificate Store. The public key is converted to the following strategy: we made the meter slightly SPKAC format. When the wizard is invoked from the challenging and by default it doesn’t allow you to go Keygen Interceptor filter (see section 2.2.2. ), we on if the score doesn’t lie in the “good” range. return this SPKAC to the filter. We also store along However, we added a checkbox that allows you to with the private key the state of the attestation disable the meter restriction altogether – in which case checkboxes in the final page of the wizard (the CSM the user gets a polite message telling something like has facilities to add property=value tags along “now you’re on your own risk, hope you know what with any object) – they will be needed later when it’s you’re doing – don’t say I didn’t warn you”. time to pick up the issued certificate and insert it in the A frequent question our users pose is “what’s a good CSM. passphrase anyway?” To try to answer that we If, on the other hand, wizard has been invoked from implemented the passphrase suggestion dialog shown the main menu, the SKPAC is sent in a HTTPS in Figure 4d. It generates passphrases suggestions message to the FreeICP.ORG Entry-Level CA (the using the Diceware method [18], which consists of destination URL is configurable but with a hardcoded generating a random number and mapping them onto a default). The Entry-Level CA responds immediately dictionary of 7776 words and common abbreviations, with the certificate in a PKCS#7 bag right in the HTTP yielding 12.92 bits of entropy per word. (The method response body. was originally designed to be performed by hand, pencil and paper using five dice tosses to select each 2.2 Filters word.) With 5 words we get more than 64 bits of Filters are routines that change the request header, the entropy, which provides good enough protection request body, the response header or the response body against brute force attacks under quite general of the HTTP requests received by our internal HTTP conditions while remaning reasonably easy to server. In our implementation, each filter can change memorize. only one of these items; the cooperation of several Our user’s feedback to the passphrase suggestion box filters is often needed to implement a single particular has been a mixed bag. Some love it and many hate it – feature. The filters are organized in two filter chains: the primary complaint is that passphrases are way the request chain and the response chain. Within a long. Many system administrators have been asking us chain, the filters are executed sequentially in the order to add a passphrase suggestion algorithm that matches they’ve been set up. Some filters depend on others, so their password policies like “8 characters with at least the chain setup tries to ensure that they are one punctuation character and a number not in the end topologically sorted. nor the beginning”. No amount of arguing that the (a) (b) (c) (d) (e) (f) Figure 4: Wizard-style UI for using the FreeICP.ORG instantaneous Entry-Level certificate issuance process. In (a) the user enters his/her name and email address, while being advised the need to be online and that notifications will be sent over email. In (b) the CA is queried to see whether that email address is already in use. If so, the CA will send an email with revocation instructions and the process is halted. In (c) the user sets up a passphrase for the private key that is about to be generated. A quality meter gives prevents the user from choosing too weak a passphrase – unless the “Enforce quality restrictions” checkbox is disabled. The status texts indicate in real time when the confirmation matches and some educational security tips are also offered. In (d) we see the passphrase suggestions dialog: ten suggestions are put forth so that the user can choose visually without revealing the passphrase to shoulder surfers. As the first character is typed, all fields turn to asterisks. Each time the user correctly retypes the passphrase causes the chosen box to blink. Typing a different one resets the counter. Cheating by using copy-and-paste works but the user is politely warned that this doesn’t help memorization. In (e), the key pair has been generated, converted to SPKAC, sent to the CA and the signed certificate has been received back. In (f) we see the new certificate and its associated private key in the certstore main window, already set as the default ID. The “Mark the Root CA as Trusted” checkbox caused the attestation of root certificate, so it’s shown as directly trusted; the “Mark all cross-certified Root CAs as Trusted” checkbox caused an attestation on VeriSign’s Root CA as well. The whole process takes 20 seconds or so for experienced users and less than two minutes for novices – most of it spent figuring out how to either please or bypass the quality meter. The user gets out of the process with all attestations already performed, so he/she will rarely have to perform manual attestations. Notice that request filters can consume the HTTP default dispatcher at the end of the chain. It then request entirely, removing it from the chain so that it becomes this filter’s responsibility to either issue the won’t reach neither the subsequent filters nor the request and insert the response back in the chain or to browser’s identity and version. This will be abort the request entirely. needed to redirect us to the Nestcape-style Filters can be divided in two main groups described in certificate issuance system in commercial web- the following subsections. based CAs. Second, it arms the Keygen interceptor filter. 2.2.1. Infrastructure Filters • Version Tag: A simple request header filter that Infrastructure filters aren’t directly involved in appends an identifier and our version numer to the implementing the security features; they primarily User-Agent header, without removing the provide services for the other filters. A description of browser’s identification. This allows the web the most important filters in this category follows, server to detect whether our tool is enabled and roughly in order from the simplest to the most perhaps offer customized functionality. For complex: instance, a client authentication-capable website could detect that Kapanga is engaged to the • Command Parser: this is a simple request header browser and offer its login URL already including filter that detects and extracts a special query the x-kapanga-cmd=addsite command. string on the form “x-kapanga- cmd=[command]” from the URL. Below we This filter is also responsible for “lying” about the have a short summary of the commands; each will browser’s identity when the command parser has be discussed in detail further along: previously received the x-kapanga- cmd=ua(string) command. It changes all http://example.com/?x-kapanga- User-Agent request headers to the specified string cmd=addsite(port,title,errpath) (typlically something like “Mozilla/5.0”). It also Adds the current site (example.com:80) to the replaces all occurences of encryption domain. TLS/SSL connections will be navigator.appVersion in JavaScripts by sent to the TCP port specified in “port”. If the certificate validation fails, the request is redirected the specified string, since most web-based to “errpath”. The parameter “title” is a user- commercial CA software uses embedded scripts to friendly added to the bookmark/favorites lists. determine the browser’s version. http://test.com:8080/?x-kapanga- • Encoding Dampers: quells any encoding cmd=delsite negotiation we can’t understand, such as gzip or deflate encodings. In our current implementation, Removes the current site (test.com:8080) from the we don’t support any encodings, so this is a encryption domain. simple filter that sets the the Accept- http://yasite.com/?x-kapanga- Encoding field of the HTTP request headers for cmd=sign(data,sig) the identity transformation. This is needed Prepares to sign the field named “data” in an web because several filters down the chain will need to form that will be downloaded as a result of this parse the HTML when it comes back. This, of request. The signature will be performed when the course, hinders any performance gains that those user hits the submit button in his/her web browser encodings might bring. Future implementations and the result will be placed in a (possible new) will replace the damper by a proper set of form field named “sig” as a S/MIME signature. decoders. http://somewhere.net/?x-kapanga- • Chunked Transfer Encoder: converts the HTTP cmd=send-usable-ids response bodies to the chunked transfer encoded Forces the request to become a POST and sends a form (see [1], section 3.6). This is needed because list of valid ultimately trusted certificates (without the response body filters will very likely change their respective private keys, of course). the length of the body, so the browser must not http://whatever.org.ar/?x- employ the ordinary strategy of relying on the kapanga-cmd=activate(sha1) Content-Length header. All that, in turn, is a Sets the ultimately trusted certificate with consequence of the fact that the body filters fingerprint SHA1 as the default for client perform on-the-fly rewriting, that is, they act upon authentication with the server specified in the each data block read from the network. The URL (in the example, “whatever.org.ar:80”) alternative would be to buffer the whole body, http://dummy.net/?x-kapanga- compute its new length after all filters had been cmd=ua(string) applied and then send it along to the browser – a bad idea because response bodies can grow This command interacts with two filters. First, it arbitrarily large, often several megabytes long, tells the Version Tag filter to change the User- which would make latency too high and memory Agent header to string, effectively lying about the consumption prohibitive. The Chunked Transfer Encoding scheme was invented precisely for this kind of situation when we don’t know beforehand the size of the HTTP object we’re transmitting. The chunked encoder converts this to: HTTP/1.1 200 OK An example may clarify what those filters accomplish. content-type: text/html Suppose our browser issues the following HTTP transfer-encoding: chunked request (indented for better readability): GET http://testserver.example.com/t1.html?x- 40 kapanga-cmd=delsite HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, Infrastructure filters demo application/vnd.ms-powerpoint, </TIT application/msword, 40 application/x-shockwave-flash, */* LE> Accept-Language: pt-br </HEAD> User-Agent: Mozilla/4.0 (compatible; MSIE <BODY> 6.0; Windows NT 5.1) <H1>Test!</H1> Host: testserver.example.com All's well. Connection: Keep-Alive </BODY> </ The full URL on the GET request gives away the fact 5 that our browser was configured to use a proxy. This HTML> request also includes a Kapanga-specific command. 0 After passing through the infrastructure filters, it would be sent over the network like this: In this example, we lowered the maximum chunk size GET /t1.html HTTP/1.1 to 64 bytes to accentuate the encoding result; in our accept: image/gif, image/x-xbitmap, actual implementation, the maximum chunk size is image/jpeg, image/pjpeg, 32Kb and it almost never gets that big because the application/vnd.ms-excel, networking layer sends it to us in even smaller chunks application/vnd.ms-powerpoint, application/msword, due to the underlying TCP buffers. application/x-shockwave-flash, */* The chunk encoder filter has some heuristics to detect accept-language: pt-br accept-encoding: identity;q=1, *;q=0 old browsers (such as IE3) that don’t support the connection: keep-alive chunked transfer encoding. In those cases, it refrains host: testserver.example.com from altering the body but it also quells the HTTP proxy-connection: Keep-Alive keepalive feature, so that the browser will rely on the user-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) + Kapanga connection termination to know when the body data 0.22 finishes. Since in this example Kapanga was not configured to relay the request to another proxy (that is, IE was not 2.2.2. Feature Filters using a proxy before the engager did its job), the URL These are the filters that actually implement the in the GET line is relative. Also notice that the security-relevant features, relying in the infrastructure command parser removed the “x-kapanga-cmd”. provided by the previous filters and the CSM: The encoding damper has also left its mark in the • Web Form Signer: this is a request body filter Accept-Encoding line telling that only the identity that acts only on POST requests with the encoding is acceptable and all others are not. We can “application/x-www-form-urlencoded” MIME also see that the version tag filter added our name and type. It is activated when the command parser version number to the User-Agent line. previously received a command of the form After the request is issued over the network, the server sign(in,out,flags). The argument “in” is responds with something like this: the name of a form field in the current page form HTTP/1.0 200 OK which the filter will get data for signing. The filter Content-Type: text/html displays a dialog box confirming the data being Content-Length: 132 signed and requesting the passphrase for the private key that will be used for signing. When it <HMTL> receives these data from the user, it creates a <HEAD> <TITLE> S/MIME signed message and encodes as a Infrastructure filters demo (possibly new) form field named “out” (if “out” is ommited, it is assumed to be the same as “in”). The flags control things like whether we want our

Test!

own certificate included in the signature, whether All's well. (b) (a) Web Form Signing Demo
Web For Signing Demo (c)
Figure 5: The web form signing filter in action. In (a) we see a minimalistic web in the browser and its source HTML. Notice the action URL with a Kapanga special command. The command parser field intercepts this command and set things up to intercept the POST request body and sign the “in” field, putting the result in a new form field named “out”. The final one in the sign command is a flag to hasve the S/MIME signer not include the signer’s certificate, just to keep the signature block small enough to fit this screenshot. In (b), the exact intercepted data that will be sign is shown in a dialog box, where the program allows the user to specify which key he/she wants to sign with and asks for the key’s passphrase. In (c), the signature has been performed and sent to the server. A script in there displays the signed block for us. For sake of brevity, we have shown only the successfull case. Lots of failure conditions are handled as well – for instance, when the signature doesn’t match, or the signed data has been changed by the client, when the user cancels without signing or when the proxy isn’t activated. to add the whole certificate chain up to the root, the request to become a POST (even if the etc. browser has sent it as a GET or HEAD). Kapanga The advantage of this approach is that we can add then builds a body with a list of PEM-encoded form signing functionality to some web ultimately trusted certificates it has. This is application just by activating Kapanga and making extremely useful because the site can know in just minor changes in the web application – if it advance which identities we can assume, inform doesn’t bother to verify the signature, it’s just a the user which ones are acceptable or not and help matter of chaning the HTML to include the sign the user select an appropriate one for login or command and storing the “out” field somewhere. registration, reducing the likelihood of frustrating A signature verification engine, however, would failures. be recommended to deal with exceptions such as The webmasters we have been working with point invalid signatures or to ensure that the signed this particular feature as the one that mostly contents is the same as previously sent (since it’s contributes for the overall user acceptance – it within the client’s control, a malicious user may makes it viable to make helpful web-based change it). certificate enrollment/registration system almost • Usable ID enumeration: This filter is triggered as simple as traditional name+password+cookie by the “send-usable-ids” command. First, it forces methods, as shown in Figure 7. (a) (b) (c) Client Auth Demo (f)
Client Auth Demo

You are: O=$SSL_CLIENT_S_DN_O,..., CN=$SSL_CLIENT_S_DN_CN
Got your cert (chain is ok, didn't check (e) revocation though):

$SSL_CLIENT_CERT
(d) Figure 6: The HTTPS Logon filterset in a client authentication scenario. In (a) the user directs the web browser to an HTTP URL containing the command for adding the site to the Encryption Domain. As Kapanga was engaged to the browser, the request is actually sent over HTTPS because the command parser filter is executed early in the filter chain. Thus, when the request reaches the HTTPS Logon filter, the site address and port is already in the Encryption Domain. In (b), the site has requested client authentication and Kapanga asks the user which certificate he/she wants to use and the passphrase of its associated private key. Unlike Internet Explorer, Kapanga doesn’t show expired, revoked or altogether untrusted certificate, nor has a “remember password” checbox to ruin the whole security of the process. In (c), and the server have sucessfully completed the TLS handshake, sent the request and got the response back, where we see that the server sucessfully received and validated the user’s certificate. In (d) we see the returned page source HTML; comparing with the source HTML template in (f), we can see that the absolute URL in (e) was rewritten (notice the change from “https” to “http”) so that the image download would pass through our proxy as well. Granted, this kind of enumeration may be abused certificate or if it’s not ultimately trusted, no by rogue sites to collect email addresses or action is performed. tracking the user’s habits. We argue this is a This command is typically used in pre-logon page necessary evil to provide a seamless HTTP Ù just before the “addsite” command to have the HTTPS transition. Just in case, we left a correct ID selected by default in the Web Site configuration option that allows the user to either Login Dialog (where the user is prompted for the disable this feature entirely or get a popup then the passphrase). site sends the enumeration command. • HTTPS Logon: this filter is activated by the • Remote ID activation: this filter is trigged by the “addsite” command previously seen by the “activate(sha1)” command. It sets the preferred Command Parser filter. Recall that this command default ID for this site (as identified by the host has three parameters: the SSL port (443 by portion of the URL) as the certificate with the default), a user-friendly site title/name and the specified SHA1 fingerprint. If we have no such error redirect URL. Figure 7: The send-usable-ids command allows the web application to provide friendly account creation assistance, explaining beforehand which certificates are acceptable and which are not and thus minimizing frustrating failures. The “login” and “register” links, use the activate command to force that particular certificate to be selected, minimizing user errors and then redirects to another URL with the addsite command, inserting the site into the Encryption Domain and starting the transition to the HTTPS site. Even so, the SSL handshake might still fail if the site’s certificate doesn’t pass Kapanga’s validation. In this case (not shown in the picture) the “errpath” parameter in the addsite command would redirect the user back to a page explaining what went wrong and offering further help. At the bottom of the page, a form allows the user to start the wizard- based certificate issuance process directly from the web page: then clicking on Issue, the wizard pops up with the name and email fields already filled in. The first thing this filter does is a purely user- CSM deems the it untrusted or if any network or friendliness action: it inserts the site URL and title handshake error happened, the dispatcher displays in the Bookmarks/Favorites list (accessible via a a dialog box explaining the failure and returns menu), unless there is already a bookmark for this down the response chain a redirect to the error site there. That way, the user can easily come back URL specified in the site’s entry in the Encryption to this site without having to remember the URL. Domain (if none was specified, the connection is simply broken). This way, the site has an Then the filter inserts the site’s address in the opportunity to display a nice message telling the Encryption Domain, which is just a simple set user that the HTTP Ù HTTPS transition failed mapping host:port pairs to SSL ports and error and maybe provide options to retry or choose URLs. Since the Encryption Domain filter is right other authentication options (such as plain old next in the chain, the request will be immediately name+password). This in direct contrast with rerouted to the HTTPS dispatcher. popular web browsers, which simply break the • Encryption Domain Filter: this filter checks connection on SSL failures, leaving the non- whether the host:port in the URL of the current technical user wondering what went wrong. request is in the Encryption Domain. If it isn’t, the Finally, if no errors occurred and the certificate is filter simply lets it follow its way on the filter held as trusted, the original HTTP request is sent chain, so it will ultimately reach the standard over the HTTP tunnel and the response inserted dispatcher and sent to the network over HTTP. back in the response filter chain. Also notice that, Otherwise, the request is taken out of the chain (so due to the SSL session caching, the whole it won’t reach the standard dispatcher anymore) verification process above happens only in the and fed to the HTTPS dispatcher, which, in its first connection to the site or when the cache entry turn, starts the SSL handshake to the port expires. specified in the site’s entry in the Encryption • URL Rewriter: This filterset is actually part of Domain. the HTTP Logon filterset described above. It acts If the server requests client authentication, the only on text/html MIME types on requests HTTPS dispatcher asks for the user’s private key through the HTTPS user agent. Its main purpose is for the default ID set for this site; if this key is not to rewrite URLs of the form: cached, the CSM will display a dialog box stating https://example.com/ the exact site name and prompting for the user’s private key. If, on the other hand, the server as doesn’t require client authentication, this step is http://example.com/ skipped. Supposing, of course, that “example.com” is in the At this point in the SSL handshake, the HTTPS encryption domain. If the site name in the above dispatcher receives the server’s certificate. If the URL is not in the encryption domain, it is left • Certificate Interceptor: this filter grabs the unchanged. response bodies in “application/x-x509- That way, any further requests initiated by {user,ca,email}-cert” MIME types. It also looks consequences of the browser parsing the current for these content-types in each section of multipart HTML will again be sent to us – recall that the MIME types as well – this is the mechanism used engager configured us as the browser’s HTTP by web sites and commercial web-based CAs to proxy only – we do not receive any HTTPS install certificates and certificate chains. The data requests the browser generates. So this filter tries is decoded (DER/PEM-armoured detection is built to ensure that all URLs in the HTML the browser in and both single certificates and PKCS#7 bags receives point to URLs with the HTTP scheme are supported) and inserted directly to the what we can proxy. Certificate Store. The discussion omitted several details for the sake If one of the inserted certificates matches a of clarity. In our implementation, it is comprised previously sent SPKAC, the automatic attestations of two filters: a response header filter for rewriting are performed. If the inserted chain contains a URLs in the Location field during redirect Root CA but no automatic attestation has messages; and a response body filter the that occurred, a dialog box pops up informing the user parses the HTML looking for tags with src, that he/she may be interested in performing a href and action parameters and rewrites only manual attestation. URLs within them – that way, any URLs within 2.3 Engagers the readable text (outside the tags) won’t be The engagers are responsible for setting up the data touched. We also made it rewrite URLs in interception in each browser by inserting ourselves in window.open JavaScript instructions, since it the proxy chain through the following process: occurs quite often in many websites. • The browser’s current proxy settings are detected The response body filter is the system’s Achiles and saved for later restoration; heel: since it is static, it misses any absolute URLs generated dynamically by embedded languages • The address and port of the proxy the browser is such as Java, JavaScript or VBScript, nor it sees currently using for sending HTTP requests is absolute URLs embedded in Flash movies or other detected and the engager signals our default plugin-specific objects. However, things work dispatcher to use this proxy. If the browser isn’t remarkably well in sites where nearly all using any HTTP proxy, we tell our default embedded URLs are relative. dispatcher to do the same and send the requests directly; • Keygen Tag Mangler: This filter replaces the tag used by Netscape-derived • The browser’s HTTP proxy settings are overwritten with “localhost:ourport”, where browsers in web forms to generate a new keypair “ourport” is the port where we’ve previously [12] by a combo box (a started a server to listen to this specific browser’s sequence in HTML requests; parlance) allowing the user to choose one of the allowed key sizes. The original name of the • The address and port of the proxy the browser is KEYGEN tag is prepended with “x-kapanga- currently using for sending HTTPS requests is keygen-”, so that the Keygen Interceptor field detected and the engager tells the HTTPS described below can intercept it. This filter is only dispatcher to use this proxy. Unlike the HTTP active when previously told so by the command proxy, however, we don’t overwrite the browser’s parser. setting. • Keygen Interceptor: this filter acts on response Implementing this seems simple, but each browser bodies of POST requests and only when the presented its own special cases. mime-type is “application/x-www-form- The engager for Internet Explorer proved to be the urlencoded”. It looks for form fields with the simplest to implement because IE has simple API calls name starting with “x-kapanga-keygen-”. Upon to change the settings and have its currently running finding it, it starts the New Digital ID Wizard instances instantaneously reload any changes made to right in the point where the user chooses the it. Slight complications arise due to the several passphrase (see Figure 4c). When the wizard is versions of IE and the API itself. The most severe is done generating the keypair, it is converted to an with IE versions 5 and above: since it supports per- SPKAC and sent over the form field with its dialup connection profiles, each with its own proxy original name (i.e., the “x-kapanga-keygen-” settings, the process above has to be performed for previously prepended is removed). each dialup profile. In the end, the IE engager we implemented works with all IE versions all the way back to version 3. Version 2 and below didn’t support A limitation of our current engager implementations is proxies at all. that they cannot handle Proxy AutoConfiguration [11], Implementing the Mozilla engager, on the other hand, which is quite popular. Since implementing this proved to be quite a challenge because of the lack of a support would require a quite capable JavaScript simple way (as far as we know) to signal its currently interpreter, we have chosen to deal with it in future running instances of any changes in its settings. versions; we felt that for the purposes of proving the Mozilla’s settings are read once during program concept, it was not essential. startup and kept in memory. We can easily overwrite Notice that engagers are just a convenience feature for the configuration files and its format is quite simple users. They’re obviously not necessary for the rest of (although figuring out where it is located means the proxy to work, so long as the user changes the messing with registry.dat /appreg file [10]). browser and Kapanga’s proxy settings manually. That This works well for inactive profiles, but not for the way, this whole system works even with browsers our active ones – the running instance doesn’t notice that implementation doesn’t have specific engagers for. All Kapanga (an external process, from its point of view) that is required is that the browser must have proxy changed the files and thus doesn’t reload them. And it support. We’ve successfully run Kapanga in overwrites our changes when saving the settings back conjunction with many other browsers such as to disk as it finishes. Konqueror, Opera and even Links (a console-based browser), just for kicks. 3 OTHER DESIGN ALTERNATIVES Before settling for the particular set of design criteria and features we described, we considered and rejected a few other alternatives. While the reasons for some of them are pretty obvious, other are quite subtle and perhaps debatable. In the next subsections we describe a few choices we had to make and the rationalie behind tem. 3.1 Traffic Interception Method Using the browsers’ native proxy support was an obivous choice – web proxy technology was Figure 8: A JavaScript program is the only way to set the proxy specifically design to intercept and forward HTTP settings in the currently running instances of Mozilla. However, traffic and it’s widely deployed and matured. Not that since changing user settings is a privileged operation, its execution we lacked choices: prompts a confirmation dialog box, somewhat thwarting the convenience of the engager. • Internet Explorer has a feature called Browser Helper Objects [15] that could make interception a The method we came up with works but is less than lot easier on that platform because we wouldn’t elegant: we generate a web page in a temporary, have to deal with next-hop proxies and its randomly-named file the local filesystem with a small particularities (PAC, multiple authentication JavaScript program that performs the changes. Then methods, etc). However, we didn’t want to confine we direct the currenly running instances of Mozilla Kapanga’s applicability to Windows only; as (via DDE [9] on Windows or X-Remote [8] protocol previously mentioned, we wanted it to work with on Unix) to open this page. Since changing those any browser on any platform; settings requires granting special privileges to the script, the first time it is run Mozilla displays a • Implementing Kapanga as a SOCKS [20] proxy confirmation dialog box, as shown in Figure 8 above. might also work, but it would involve guessing port numbers where HTTP traffic goes. Besides, The paranoid may regard this procedure as opening up not all proxies support SOCKS; a vulnerability itself – from there on, any local scripts (using the “file:///” scheme) may change Mozilla’s • Redirecting the socket API calls would not only preferences for that profile. It could have been worse, require the same port number guesswork, but it though: we considered and rejected the idea of would require a lot more system-dependent code avoiding the creation of a temporary file by sending and it wouldn’t allow Kapanga and the browsers the Javascript program over HTTP – that would mean to run on different machines. the user should allow script execution over the 3.2 The Pure-Scheme vs. Cross-Scheme Dilemma “http://” scheme, which would open it up to abusive Kapanga uses what we call a cross-scheme system: scripts from anywhere on the Internet. when a site is in the Encryption Domain, we effectively map portions of the HTTPS scheme’s address space into the HTTP’s address space. That is, • Performance would suffer, since we’d have three the browser has no notion on whether the request is encryption/decryption rounds: the browser going through HTTP or HTTPS – this state encrypts the data, Kapanga would decrypt it, information is in Kapanga’s Encryption Domain. This modify it and reencrypt it again; has consequences: • It wouldn’t work on browsers without native SSL • Bookmarks made when a site is in the encryption support; in contrast, the cross-scheme approach domain will probably not work when the site is allows Kapanga to work even if the browser not in the encryption domain or when Kapanga is doesn’t support SSL; not running at all (unless the site designer was • Writing and releasing the code of a portable silent very careful to handle this); auto-engaging SSL spoofer would be more like • We had to create the URL Rewriter Filter to force giving a powerful weapon to the blackhats than a absolute URLs embedded in the HTML back to powerful protection to the average user. us. As previsouly mentioned, though, this fails Yet another advantage of the cross-scheme appoach is with dynamically generated URLs. that we give the user the choice of not using Kapanga Earlier in the design process, we considered – and at all if he/she feels like, so we neither mess nor risk to rejected – what we called a pure-scheme system: we break the user’s web banking systems and other would actually implement two proxies, one strictly critical applications they already have running. HTTP to HTTP and the other strictly HTTPS to HTTPS. Given that the namespaces don’t collide, there 4 CONCLUSIONS AND FUTURE WORK would be no need for a URL Rewriter filter nor would We described the architecture of a solution for we have problems with bookmarks. perfoming the cryptographic and user interface aspects This sounds like a good idea if we think only in terms of HTTPS channel establishment and web form of the pure HTTP proxy; however, given that SSL was signature outside of the web browser. The key idea is specifically designed to be resistant to interception and to implement the crypto services in a proxy that tampering, the pure HTTPS proxy would have to be, in rewrites the HTML on the fly and converts it to fact, a generic HTTPS spoofer/man-in-the-middle HTTPS when appropriate, so we can bypass the attack. browser’s and protocol limitations while retaining compatibility. Thus, any browser with proxy support From a purely cryptographic point of view, this is can be used – the user is not forced to adopt any quite easy to implement: during the initial SSL particular web browser. Another advantage is that our handshake, we send the browser a fake server approach does not depend on any proprietary certificate generated on the fly. From the user interface architecture such as ActiveX or Java. point of view, on the other hand, this has a problem: it triggers the browser’s SSL warning dialogs, since the Our primary motivation was to play with newer user fake certificate isn’t signed by a CA chain the browser interface concepts to make client-side PKI easier to trusts. This is clearly unnaceptable, not only in light of use. A few results stand out: in other to make sites our philosophy of non-intrusiveness and minimum with client authentication that user’s didn’t hate, we hassle for the users, but also because SSL-derived user had little choice but to address a few protocol and user interface problems are exactly what Kapanga was interface gaps: originally intented to solve in the first place. • A web site should be able to enumerate the user’s We could make the SSL spoof work silently if we certificate so as to offer assistance in registration inserted a new root certificate in each browser’s as preparation for the HTTP-to-HTTPS transition certificate store, but that would bring disadvantages: (the SSL handshake with its certificate validation first, it would again limit Kapanga to run in the same process); computer as the browser (a restriction we didn’t want • There had to be a way to redirect the user to an to have); second, the exact mechanism for inserting URL with a nice explanation, continuation options new roots varies from browser to browser: IE stores or alternative authentication methods when the trusted root CAs in the Windows Registry, while SSL handshake fails. It’s just not acceptable to Mozilla-derived browsers use a Berkeley-DB file. This break the connection and leave the user with a would increase the amount of platform-specific code cryptic error message; Kapanga would have – something we’ve been trying to • The certificate issuance process shouldn’t be so minimize all along –, not to mention that the process fragile as to break because of lack of ActiveX would fail if Kapanga runs without the proper upgrades, different browser versions or the phase privileges to write to those certstores. of the moon. Nor it should induce the user to store There are other arguments against the SSL spoofer and the private key without some effort to set up a the pure-scheme idea: decent passphrase. The process must be simple, reliable and hassle-free. Having it instantaneous is a plus – with so many online services with Horacio and Theco are comic book characters from instantaneous registration processes, it is hard to Mauricio de Sousa Produções that are arguably part of justify the severe identity validation procedures of Brazilian pop culture, used here for entirely non-profit most CAs; illustration purposes. • There really should be a simple way to do such a 6 REFERENCES simple thing as signing a web form. 1. Tim Berners-Lee et al., RFC 2616: Hypertext The implementation of those features in an external Transfer Protocol – HTTP/1.1, 1999, proxy enabled us to bypass the browsers limitations http://www.faqs.org/rfcs/rfc2616.html while providing the illusion that those features were 2. Eric Rescorla, RFC 2818: HTTP Over TLS, 2000, “augmented” to the browser in an non-intrusive way. It http://www.faqs.org/rfcs/rfc2818.html also required minimal or sometimes no change to the server side at all: nothing needs to be changed for 3. Eric Rescorla, SSL and TLS: Designing and client-based HTTPS authentication; a simple change in Building Secure Systems, 2001, Addison-Wesley, the action URL in HTML forms enables form field ISBN 0201615983. signature (bigger changes may be needed if the 4. Marco Carnut, Cristiano Lincoln Mattos, Evandro application needs to validate the signatures); and small C. Hora & Fábio Silva, FreeICP.ORG: Free changes to the HTML page where the Nestcape vs IE Trusted Certificates by Combining the X.509 issuance process decision is made is enough to support Hierarchy and the PGP Web of Trust through a Web-based commercial CAs. Collaborative Trust Scoring System, 2003, The price of this “backwards” compatibility is paid in Proceedings of the 2nd PKI Research Workshop, the considerable complexity of the architecture and the http://middleware.internet2.edu/pki03/presentation horrible contortions our tool has to go about to s/02.pdf implement them. Some problems may not have a good 5. Ari Luotonen, Tunneling TCP based protocols solution at all, such as the static nature of the URL through Web proxy servers, 1998, rewriter filter not being able to handle dynamically http://www.web-cache.com/Writings/Internet- generated URLs; this limits the tool’s applicability to Drafts/draft-luotonen-web-proxy-tunneling-01.txt “well behaved” sites only. 6. Steve Lloyd et al, Understanding Certificate Path There are many worthwhile future improvements on Construction, 2002, PKI Forum, sight. Making the proxy work for generic TCP http://www.pkiforum.org/pdfs/Understanding_Pat connections as well as HTTP may help extend the use h_construction-DS2.pdf of client-side authentication for several other protocols 7. Steve Lloyd, AKID/SKID Implementation such as SMTP, POP3, VNC, X and many others. Guideline, 2002, Extending the program to act as a Mail Transfer Agent http://www.pkiforum.org/pdfs/AKID_SKID1- (since every MTA is kind of a proxy) holds the af3.pdf potential for allowing us to make the same for mail 8. Jamie Zawinski, Remote Control of Unix clients: having the digital signature generation and Netscape, 1994, verification be performed out of the mail client. Going http://wp.netscape.com/newsref/std/x-remote.html further in this idea, we could also add support for encryption and decryption to allow message 9. MSDN Library, About Dynamic Data Exchange, confidentiality. We are also working on making the http://msdn.microsoft.com/library/default.asp?url= CSM support PGP and SSH keys as well in order to /library/en- achieve Jon Callas’ concept of format agnosticism us/winui/WinUI/WindowsUserInterface/DataExch [21], consonant with our philosophy of bridging the ange/DynamicDataExchange/AboutDynamicData PKIs together. Exchange.asp 10. Daniel Wang, Mozilla Profile registry.dat File 5 ACKNOWLEDGEMENTS Format, Thanks go to our co-developer Tiago Assumpção and http://wangrepublic.org/daniel/mozilla/registry to Felipe Nóbrega for implementing both the CAs used 11. Nestcape Inc., Navigator Proxy Auto-Config File for the instantaneous certificate issuance and the public Format, 1996, CSM server. We’d also like to thank Justin Karneges http://wp.netscape.com/eng/mozilla/2.0/relnotes/d for writing the first versions of the Q Cryptographic emo/proxy-live.html Archictecture [19] on which our implementation is based. We are also grateful to the anonymous 12. Netscape Inc., Netscape Extensions for User Key reviewers for their invaluable criticisms and Generation, suggestions for this paper. http://wp.netscape.com/eng/security/comm4- keygen.html 13. Arnold G. Reinhold, The Diceware Passphrase Home Page, http://world.std.com/~reinhold/diceware.html 14. Sean Smith, Effective PKI Requires Effective HCI, ACM/CHI Workshop on Human-Computer Interaction and Security Systems, 2003, http://www.cs.dartmouth.edu/~sws/papers/hci.pdf 15. Dino Esposito, Browser Helper Objects: The Browser the Way You Want It, 1999, Microsoft Corp., http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dnwebgen/html/bho.asp 16. RSA Data Security Inc, RSA Keon WebPassport, http://www.rsasecurity.com/node.a sp?id=1230 17. Verisign Inc., Go! Secure for Web Applications, http://www.verisign.com/products- services/security-services/pki/pki-security/pki- solution/web-application/ 18. John Marchesini, Sean. Smith & Meiyuan Zhao, Keyjacking: the surprising insecurity of client-side SSL, http://www.cs.dartmouth.edu/~sws/papers/kj04.pd f 19. Justing Karneges, Q Cryptographic Architecture, http://delta.affinix.com/qca/ 20. M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas & L. Jones, SOCKS Protocol Version 5, http://www.faqs.org/rfcs/rfc1928.html 21. Jon Callas, Improving Message Security With a Self-Assembling PKI, 2003, Proceedings of the 2nd PKI Research Workshop, http://middleware.internet2.edu/pki03/presentation s/03.pdf A Proxy-Based Approach to Take Crypto Out of The Browsers for Better Security and Usability Marco “Kiko” Carnut Evandro Hora 4th PKI R&D Workshop NIST, Apr/2005 Agenda  Motivation What we wanted to do and why we couldn’t  Solution: a local filtering/rewriting proxy Architecture Filters and features  Conclusions & Future Directions Disclaimer  We’ll be talking network protocols nuts and bolts Focus on what we needed to change to seize control of PKI-related UI From a pragmatic implementation point of view (programmers’ talk)  We won’t be talking HCI We don’t claim our UI is the best - It’s a work in progress at the very best A proper analysis from an HCI standpoint would require entirely different approaches and methodologies But we do claim our tentative UI is already better than most browsers’ What we wanted to do  Sign a web form IE doesn’t do this natively Java Applets + CAPICOM  too many installation hassles; nonportable  Do HTTPS Client Auth IE’s logon screen is confusing - shows expired certs along with valid ones - Hard to know the right cert to use for each app IE’s logon screen is insecure - offers to save your passphrase Bad failure handling - SSL failures break the connection; the app has no chance to display a nice error message or offer alternative auth methods Cert issuance on IE Besides... getting a client cert is such a hassle click count= 1 9 2 11 3 10 12 13 4 6 5 8 7 24 16 15 14 23 22 17 20 18 19 21 24 The Unfinished Paper  A follow-up to Alma Whitten’s seminal work “Why Johnny Can’t Encrypt: An Usability Evaluation of PGP 5.0”  Never finished... It would be way too depressing... all problems and no solutions. The Central Idea  Let’s do the crypto out of the browser In a separate program - So we become free to try new UI ideas A filtering/rewriting selective crypto proxy - A local proxy, so we can make the user feel like it’s part of the browser  Leave the browser to do only what it’s good at: render web pages Overall Architecture HTTP 3128/tcp Filter #1 Infrastructure Some Filters web site Filter #2 . . . . . . Encryption HTTPS Engagers Features Domain Filters Dispatcher Configures the Filters Web Form browser to use ourselves as proxy Signer Filter . . . . . . Certificate Filter #n Store Manager HTTP Dispatcher Infrastructure Filters  Command Parser Filter catches URLs of the form: - ?x-kapanga-cmd=command(arg,...) then sends the arguments to the appropriate filters  Version Tagger Filter Adds Kapanga version number to the User-Agent header Allows the site to determine whether Kapanga is active and thus provide Kapanga-specific functionality Infrastructure Filters  Encoding Damper Disable Encodings Kapanga doesn’t understand (gzip/deflate) Should be replaced by filters to properly perform the decoding  Chunked Transfer Encoder Converts the response body to the transfer-encoded form This is needed because on-the-fly rewriting changes the body length, thus invalidating the Content-Length Feature Filters  Web Form Signer Activated by - ?x-kapanga-cmd=sign(in,out,flags) Intercepts POST requests with the application/x-www-form-urlencoded MIME type Decodes the form data Signs the data in the field specified by in Saves the result in out flags controls whether to include the user’s own cert, the whole cert chain up to the root, etc. Philosophical question: should we do that for multipart/form-data as well? (Signed File Upload) Demonstrations  Cert Store Manager (CSM) Trust Rules and such  Web Form Signing Feature Filters  Web Form Signer Activated by - ?x-kapanga-cmd=sign(in,out,flags) Intercepts POST requests with the application/x-www-form-urlencoded MIME type Decodes the form data Signs the data in the field specified by in Saves the result in out flags controls whether to include the user’s own cert, the whole cert chain up to the root, etc. Philosophical question: should we do that for multipart/form-data as well? (Signed File Upload) Feature Filters  HTTPS Logon Activated by - ?x-kapanga-cmd=addsite(p,t,e,f) Adds the current site (host:port) to the Encryption Domain, along with the (p, t, e, f) tuple p: port for HTTPS t: site title (for bookmarking) e: error path: where to go if SSL cert validation fails f: flags Feature Filters  Encryption Domain Filter If the request’s host:port is in the Encryption Domain - Remove the request from the filter chain - Route it through the HTTPS Dispatcher  It handles the SSL negotiation and cert validation according to the current CSM rules  Handles client authentication as well with a nice friendly UI  If cert validation fails, redirects to the “error path”: site can offer assistance or alternative authentication methods Otherwise, let the request pass untouched Feature Filters  URL Rewriter Filter Modifies the HTML to change https:// URLs to http:// Acts only on responses coming back from the HTTPS Dispatcher If we didn’t do this, the next image, form, link, etc., would not be handled by Kapanga - Kapanga is an HTTP-only proxy It is Kapanga’s Achile’s Heel: it’s purely static - can’t handle dynamically generated URLs - in our experience, this has not been a deterrent Feature Filters  HTTPS Logoff Activated by - ?x-kapanga-cmd=delsite  Current ID Activator Activated by - ?x-kapanga-cmd=activate(sha1) Makes the ID whose cert sha1 fingerprint is sha1 the active one Used just after a send-usable-ids The site can automatically select an appropriate ID - But the user can override if he/she wishes: the only way cert validation might fail Feature Filters  Usable ID Enumerator Activated by - ?x-kapanga-cmd=send-usable-ids If the request is GET, change it to a POST Send a message listing all the ultimately trusted certificates - i.e., those that we have a corresponding private key for Allows the site to offer assistance in selecting the appropriate cert to log on Feature Filters  New Cert Generation Activated by - ?x-kapanga-cmd=new-express- cert(name,email) Starts Kapanga’s built-in New Certificate Wizard Site can direct the user to get a new cert Uses FreeICP-style instantaneous “guest-level” certificate Satisfies the web users’ expectations to get registered immediately Still not as fast as name+pwd+cookies but not too far behind Feature Filters  New Cert Generation Activated by - ?x-kapanga-cmd=new-express- cert(name,email) Starts Kapanga’s built-in New Certificate Wizard Site can direct the user to get a new cert - Uses FreeICP-style instantaneous “guest-level” certificate Satisfies the web users’ expectations to get registered immediately Still not as fast as name+pwd+cookies but not too far behind - most importantly, users don’t reject it Our version of Jon Callas’ “Self-Assemling PKI” concept: we want every app to be an invitation for PKI enrollment Conclusions  More usable, more secure HTTPS Now we can make HTTPS sites with client auth without the users hating us There’s improvement of HTTPS server cert validation as well We can get rid of the browsers’ crypto vulns and bad UIs  Portable: we can do it the same way regardless of browser/platform  Web apps do need a few changes  Application-level proxies might be a good place to put PKI-related functionality in a backwards compatible way Future Directions  More Nice Useful Filters Web-based signature verification,... making the filter system pluginnable  Implement generic proxies “Stunnel on steroids”  Make enrollment even simpler  Make Kapanga an MTA How about all that for email as well?  Implement OpenPGP support Jon Callas’ “Format Agnosticism” concept The best of both worlds Thank you! Questions? Real Protection against Real Digital Threats kiko@tempest.com.br Pairing Based Cryptography Standards Terence Spies VP Engineering Voltage Security terence@voltage.com Overview • What is a Pairing? • Pairing-based Crypto Applications • Pairing-based Crypto Standards What is a Pairing? • An old mathematical idea • It “pairs” elliptic curve points • Has a very interesting property called bilinearity: Pair(aB, cD) = Pair(cB, aD) • This property makes for a powerful new cryptographic primitive • Popular cryptographic research area (200+ papers) What can Pairings do? • Identity based encryption • Encryption where any string (like an email address) can be a public key • Identity based key exchange • Key exchange using identities • Short signatures • 160-bit signatures • Searchable encryption, and others Identity-Based Encryption (IBE) • IBE is an old idea • Originally proposed by Adi Shamir, co-inventor of the RSA Algorithm in 1984 • Fundamental problem: can any string be used as a public key? • Practical implementation: • Boneh-Franklin Algorithm published at Crypto 2001 • First efficient, provably secure IBE scheme Identity-Based Encryption (IBE) The ability to use any string makes key management easier • IBE Public Key: alice@gmail.com • RSA Public Key: Public exponent=0x10001 Modulus=13506641086599522334960321627880596993888147 560566702752448514385152651060485953383394028715 057190944179820728216447155137368041970396419174 304649658927425623934102086438320211037295872576 235850964311056407350150818751067659462920556368 552947521350085287941637732853390610975054433499 9811150056977236890927563 How IBE works in practice Alice sends a Message to Bob Key Server 2 Receives Requests 3 Private Key private key, for bob@b.com authenticates bob@b.com alice@a.com bob@b.com 1 Bob decrypts with 4 Alice encrypts with Private Key bob@b.com How IBE works in practice Charlie sends a Message to Bob Key Server Fully off-line - no connection to server required bob@b.com charlie@c.com bob@b.com 1 Charlie encrypts Bob decrypts with 2 with bob@b.com Private Key How Pairings Lead to IBE • Setup • Key generator generates secret s, random P • Gives everyone P, sP • Encryption • Alice hashes Bob@b.com -> ID • Encrypt message with k = Pair(rID, sP) • Send encrypted message and rP • Key Generation • Bob authenticates, asks for private key • Key generator gives back sID • Decrypt • Bob decrypts with k = Pair(sID, rP) • Bob’s k and Alice’s k are identical IBE’s Operational Characteristics • Easy cross-domain encryption • No per-user databases • No per-user queries to find keys • State of the system does not grow per user • Key recovery • Accomodates content scanning, anti-virus, archiving and other regulatory mechanisms • Keys still under control of enterprise • Fine-grained key control • Easy to change authentication policy over time • Revocation handled without CRLs IBE and PKI - Complementary Strengths PKI • Maximum protection Sweet Spots for PKI • Works well for signing/authentication • Authentication • Requires roll-out • • Signing generate keys for users • Certificate managment • Inside the organization Identity-Based Encryption • Good for encryption • no key-lookup Sweet Spots for IBE • revocation is easy • Encryption • Ad-hoc capable • requires no pre-enrollment • Inside and outside • the organization Content scanning easy Other Pairing Applications • Short Signatures • BLS scheme and others yield 160-bit signatures • Half the size of DSA signatures • Have other interesting properties • Can aggregate signatures • Allows, for example, a single signature on a cert chain • Verifiable encrypted signatures • Use in fair exchange, other protocols • Searchable Encryption • Key Exchange Standards Activities • IEEE Study Group formed last Monday, as part of the P1363 Group • Goal is writing and submitting a PAR, defining the mission of the standards group • 24 participants from various countries and industries • Technical content drafts soon • Pairings module: Hovav Shacham, Stanford • IBE module: Mike Scott, Dublin City University • Draft PAR agreed, to be submitted Standards Philosophy • Model after past IEEE cryptographic standards • Standardize algorithms, but not protocols • e.g. formats for IBE encrypted email would be part of a different standard • Don’t block future standards based on PBC • Allow for amendments that build on parts of this standard • Separate IBE and PBC layers • Limit scope to keep the task manageable • Focus on one set of algorithms, split off other types of algorithms into separate standards Proposed Structure of an PBC/IBE Standard Pairing Based Crypto Layer and Algorithm Layers IBE based Protocols Other e.g. IBE email, stds key request etc. 1363 Identity based Identity-Based Signatures key exchange Encryption Pairing Based Cryptography e.g. pairing, algorithms to compute pairings, curve types, curve parameters Current Discussion Points • Scaling Security to 128/256 bits • Separation between pairing layer and crypto methods • Curve families for embedded and hardware implementation For More Information • On 1363 activities: http://grouper.ieee.org/groups/1363/WorkingGroup/ • On pairing based crypto • Paulo Barreto’s Pairing Based Crypto Lounge http://paginas.terra.com.br/informatica/paulobarreto/pblounge.htm • On IBE http://crypto.stanford.edu/ibe/ http://www.voltage.com Side-Effects of Cross-Certification James L. Fisher, Ph.D. Mitretek Systems, Falls Church VA jlf@mitretek.org While many organizations lean towards automatically grants that peace of mind, but cross-certification with bridge certification rather that it is standard practice for each authorities (BCAs) for wider PKI party considering cross-certification to interoperability, there are many hidden scrutinize the other party’s pre-issuance details that can affect operating capabilities identity vetting policies, private-key as well as legal standings. The purpose of protection policies, CA and directory this paper is to share lessons learned to infrastructure operational policies, etc. Thus, help the reader to understand implications an issued cross-certificate represents a of choosing a cross-certificate based trust thorough background check with acceptable model. Topics covered include: findings. X.500/LDAP certificate directory Issued cross-certificates can be used to implementation and interoperability dynamically assemble a chain of certificates requirements; transitive and asymmetrical called a trust path which spans the gap trust; choosing the proper trust anchor; between the certificate issuer and the cross-certificate policy mappings; and relying party. The complete set of Certification & Accreditation requirements. certificates comprising the certificate trust This paper does not examine the trust path path (including supporting time-specific discovery process—it focuses on the validity statements) forms a tangible record necessary, enabling configuration of trust that can be stored for future components that enable path discovery and evidence of due diligence. This might be path validation to be automated. necessary for institutional archival purposes or to satisfy National Archive and Records There are technical solutions to the issues Administration (NARA) requirements. presented herein. However, due to their inherent complexity, a discussion of alternative solutions is beyond the scope of Directory Interoperability this paper. The operating authority of a BCA typically provides a publicly available X.500 or LDAP Benefits of Certificate Bridges directory for publishing issued CA certificates, cross-certificates, and often One of the primary advertised benefits of a certificate revocation lists (CRLs). Equally certificate bridge is that it allows the relying important, these X.500/LDAP directories are party to enjoy the benefits of a larger trust configured to facilitate trust path discovery domain while not being required to be an and validation by providing chaining to, or integral part of the certificate hierarchy of referrals to, all other CA directories to which that other trust domain, all while trusting cross-certificates have been issued. The only one trust anchor—a public key which is intent is to provide a one-stop-shop virtual within its own trust domain. directory from which all relevant certificates The other benefit is that the relying party and CRLs can be retrieved during the path can also be relatively sure of the certificate discovery and validation processes. holder’s identity, based on the trust placed In practice, each cross-certifying in others to validate an organization's organization typically has its own identity. It’s not that cross-certification X.500/LDAP directory to which its own The following list describes the cross- users (certificate issuees and/or employees) certifications that have occurred between point the LDAP clients in their local the above fictitious entities, and the validation engines, and if the requested resulting trust mesh appears in Figure 1: certificate or CRL does not fall under that • The Government Bridge—GBA— local directory's base distinguished name (with base DN ou=GBA, o=Upper (DN), a superior reference chains (transparently to the user) to the master Government, c=US) has cross- BCA for retrieval. No matter where the certified with only: certificate or CRL resides, it is returned to • GI (with base DN ou=GI, the LDAP client. Without such chaining, o=Upper Government, there is currently no way for a desktop c=US) LDAP client to discover what directory to • UBA (with base DN o=edu, connect to for retrieval of a certificate or c=US) CRL. This necessary processing has • Neighboring Nation (with interesting implementation implications. base DN c=NN) • The University Bridge (UBA) has First, the BCA directory must be able to also cross-certified with: resolve any base DN that could ever form a trust path through that BCA. An illustration • The original Enormous State will help in understanding the details. University infrastructure, ESU1 (with base DN o=ESU In the examples we use in this paper, Provosts, c=us) assume the existence of the following • The new Enormous State fictitious PKI participants: University infrastructure, • A Government (Certification) Bridge ESU2 (with base DN o=ESU Authority/Architecture (GBA) Provosts, c=us, dc=esu, • A Government Institution (GI) dc=edu) • A Neighboring Nation Bridge • The Neighboring Nation has also Authority/Architecture (NNBA) cross-certified with: • A University Bridge • The World Wide Council Authority/Architecture (UBA) (with base DN dc=int) • An older, legacy PKI system at the • The World Wide Council cross- Enormous State University (ESU1) certifies with: • A newer PKI system at the same • The Random Transoceanic university (ESU2) Nation (with base DN c=RTN) • A World Wide Council (WWC) • A random transoceanic nation (RTN) GI GBA NNBA WWC UBA RTN ESU1 ESU2 Figure 1: Cross-Certification Between Trusting Partners Figure 1 allows us to see more clearly the • Name context: a subtree of a many and varied trust paths that can be directory, and is identified by the DN formed. For instance, through certificate of the topmost entry (the "base DN"); bridges and cross-certificates, the in many commercial databases, a Government Institution should be able to DSA's database can contain more trust digitally signed messages from the than one name context Enormous State University, regardless of • Cross-reference: specifies a name whether the signer’s certificate was issued context (usually within a remote from ESU’s old or new PKI infrastructures. DSA) that is not a child of this DSA's Additionally, cross-certificates would also name context; a cross-reference allow the Government Institution to trust typically points directly to the entry in digitally signed messages from the Random the name context hierarchy Transoceanic Nation—this trust path may or • Subordinate reference: specifies a may not be intentional or desired, as we will name context (usually within a discuss later. Let us now look at the remote DSA) that is a child of this certificate/CRL directory configurations DSA's name context required to enable a relying party to easily • Superior reference: specifies the discover and validate a trust path. parent DSA that holds entries outside this DSA; only one superior Before discussing the supporting certificate reference per DSA is permitted directories, it will be helpful to review the definition of key X.500 directory knowledge For complete directory chaining, the references and concepts: (fictitious) US-based certificate directories are configured as follows, with Figure 2 • Directory Server Agent (DSA): the representing the same information software providing the X.500 pictorially: directory service for a particular hierarchal directory information base • The GI directory DSA is rooted at (DIB) ou=GI, O=Upper Government, c=US, and has one superior reference to the GBA directory • The ESU directory has: • A subordinate reference from • One DSA rooted at o=ESU the DN o=ESU Provosts, Provosts, c=us c=us to the original ESU • A second DSA (or a second directory naming context under the • A cross-reference from the first DSA) rooted at o=ESU DN c=NN to Neighboring Provosts, c=us, dc=esu, Nation's border directory dc=edu • A cross-reference from the • One superior reference to the DN dc=edu to UBA's second UBA directory DSA • The UBA directory has: • A cross-reference from the • One DSA rooted at o=edu, DN dc=int to the WWC’s c=US border directory • A cross-reference from the • A cross-reference from the DN o=ESU Provosts, c=us DN c=RTN to the RTN’s to the original ESU directory border directory • A second DSA (or a second • (no superior references) naming context under the first DSA) rooted at dc=edu (We leave it as an exercise to the reader to • A subordinate reference consider the cross-references needed at the under the second DSA from WWC and RTN border directories.) the DN o=ESU Provosts, Notice this very important fact: in order to be c=us, dc=esu, dc=edu to able to retrieve (via chaining) certificates the new ESU directory issued by RTN’s CA, the GBA directory • A superior reference to the must include a knowledge reference for the GBA directory c=RTN DN (pointing to the RTN directory) • The GBA directory has: even though the GBA did not directly cross- • One DSA rooted at c=US certify with the RTN. This requirement has • A subordinate reference from potentially serious implications on how the DN ou=GI, o=Upper easily a BCA can dynamically expand to Government, c=US to the GI accommodate indirect trust agreements. • A subordinate reference from the DN ou=UBA, o=edu, c=US to the UBA directory NNBA c=NN GBA c=US cref(c=NN) cref(dc=int) cref(c=RTN) cref(dc=edu) subref(ESU Prov) o=Upr Govt o=edu subref(ou=GI) subref(ou=UBA) GI UBA ou=GI, o=Upr Govt, c=US o=edu, c=US dc=edu cref(o=ESU Prov, c=US) ou=UBA subref(ou=ESU Prov, c=us, dc=esu) ESU o=ESU Prov, c=US ou=ESU Prov, c=us, dc=esu, dc=edu Figure 2: Directory Chaining Agreements, and Subordinate and Superior References Notice that because of DN naming • cross-references conventions chosen, and how each DSA is • subordinate references rooted, both GBA and UBA directories need • superior references a cross-reference from the DN o=ESU Fortunately, these capabilities are found in a Provosts, c=us to the original ESU number of commercial X.500 directories, directory. such as: i500 by PeerLogic; eTrust by One can easily see how quickly border Computer Associates; M-Vault by ISODE. directory configuration becomes However, Microsoft Active Directory does complicated when multiple BCAs cross- not support superior references, non-local certify. Each BCA must be configured with cross-references, or non-local subordinate knowledge of all possible directories references. Therefore, organizations traversed along a trust path, even if the wishing to provide a publicly accessible BCA did not cross-certify directly with the certificate directory (often called a border corresponding CA. directory) to their relying parties suitable for use in automated path discovery should As seen, each border directory needs the export all necessary certificates and CRLs capability of supporting: from their Microsoft Active Directory and • multiple root DSAs or multiple name import into a directory supporting the contexts within a single DSA aforementioned types of references. Alternatives: regulations, let us assume that GI directors would prefer that there be no valid The BCA directory was required to provide certificate trust path from GI to a multitude of cross-references and Forbiddenstan. subordinate references because directory chaining was desired. One design To prevent the formation of such a trust alternative is to have the BCA directory path, cross-certificates must be re-issued to simply return referrals to only those specify new name constraints or path length directories with which it is directly cross- constraints. There are two logical places in certified. But this presents two problems in the trust chain where such a filter could be today's environments: positioned. Since this is a federal law, the GBA’s cross-certificate issued to the NNBA • Many LDAP clients still can not could contain a name constraint to filter out process directory referrals Forbiddenstan’s c=FB DN. However, since • Trust paths traversing more than other domestic humanitarian-oriented one bridge would not be discovered government agencies might have legitimate if the pertinent certificate fields needs to trust Forbiddenstan-signed contained only DN-formatted documents, a nationwide filter might not be information and not URI-formatted appropriate. Therefore, a GI itself might information need to insert name constraints into the Directory chaining would not be necessary if cross-cert it issues to the GBA. Additionally, all certificates had properly formatted AIA all other relying parties would similarly need fields, and the local validation client could to be aware of this political situation and understand all AIA formats. However, one place appropriate name constraints in their missing or improperly formatted AIA field cross-certificates. would destroy the ability to discover a trust While this method works, it is very difficult to path. envision all necessary path constraint needs—expressed either as path permitting Transitive Trust or path inhibiting rules—before cross- When CAs cross-certify, the phenomenon of certificate issuance. And, re-issuance of a transitive trust comes into play. Such cross-certificate is not without its labor costs. indirect trust may or may not be intended or Revoking previously issued cross- welcomed. An internationally oriented certificates will also be necessary to force illustration will make the side-effects clearer. validation engines that pre-cache the validation paths to refresh themselves. Let us extend the example of the previous More importantly, the need to restrict certain section to include one additional cross- trust paths is typically not realized until after certificate pair. Assume that the very an “inappropriate” trust path is formed. recently formed country of Forbiddenstan has also cross-certified with the World Wide Choosing the Proper Trust Council for the purpose of discussing commercial trade. Consequently, there is Anchor now a new trust path from the GI, through Another challenge of a multiple cross- the GBA, through a Neighboring Nation, certificate environment is choosing the through the World Wide Council, to correct trust anchor and certificate policies Forbiddenstan. Let us also assume that on which to filter. Complicating factors "the United States maintains a broad include: embargo against trading with Forbiddenstan, and most commercial imports from • Asymmetrical policy mappings Forbiddenstan are prohibited by law.” And • The possibility of multiple trust paths finally, to ensure compliance with federal • Unidirectional cross-certification mappings found in the cross-certificate (e.g., a GBA may issue a cross- issued by Algonk to the GBA, the State of certificate to a military to facilitate Algonk views GBA Medium as mapping to GBA-centric trust path discovery, but Algonk Level B. the military BCA may choose to not Typically, the trust anchor of choice is a issue a cross-certificate to that GBA) public key within one’s own issuing Policy mappings are often placed in cross- hierarchy. However, let us consider the certificates for the purpose of declaring how case were a centralized, organization- the levels of assurances (LOAs) in the independent validation service (employed subject’s domain translate to the LOAs in by a GBA) is being established to validate the issuer’s domain. In order to make use only certificates that are GBA Medium or of these policy mappings, RFC3280 equivalent. Let us examine two trust anchor indicates that path discovery and validation options and their implications. algorithms must specify a trust anchor and a If the trust anchor is a GBA root public key, set of acceptable certificate policies (in the then the certificate policy OIDs on which to trust anchor’s domain). Additionally, if the filter should be GBA Medium. In this case initial set of acceptable certificate policies is policy-filtered trust paths can be found from a subset of those mapped, then the effect is the GBA to (a) Algonk Level C certificates, to filter out any trust paths involving but not to other Algonk LOAs, and (b) any certificates with LOAs that do not map to other issuers' certificates that GBA maps to that initial set. GBA Medium LOA. Consider the following example. The Alternatively, the validation service operator (fictitious) State of Algonk has one CA (with could reason that since Algonk certificates one private key) issuing end-entity are validated so often, the dynamically certificates with one of four levels of discovered trust path for Algonk certificates assurance (LOAs): Level A, Level B, should be made as short as possible for Level C, and Level D. Independently, GSA reasons of efficiency. To shorten the trust has three LOAs: Small, Medium, and Large. path, the trust anchor is chosen to be the But when the State of Algonk cross-certified State of Algonk’s root public key. Since the with the GBA, Algonk submitted GBA views only Algonk Level C certificates documentation describing only their Level C as equivalent to GBA Medium LOA, the LOA, therefore the cross-certificate issued initial set of acceptable certificate policy by GBA to Algonk contains only one policy OIDs is just the policy OID representing mapping: Algonk Level C maps to GBA Algonk Level C. Obviously, trust paths will Medium. be found to Algonk Level C certificates. Furthermore, the cross-certificate pair However, the policy mapping in the Algonk- between the GBA and the Algonk contains issued cross-certificate (i.e., the cross- asymmetrical policy mappings. Why? certificate going in the opposite direction) Because each party’s Policy Authority (PA) states that GBA Medium maps to Algonk could independently evaluate the other Level B. Since Algonk’s Level B certificate party’s Certificate Policy/Certification policy OID is not in the initial set of Practice Statement (CP/CPS), and there is acceptable certificate policies, no other no guarantee the parties will view each issuer's certificates mapping to other’s policies equally. Consequently, GBA Medium (as determined GBA’s point of according to the policy mappings found in view) will be accepted (i.e., no valid trust the cross-certificate issued by the GBA to path will be discovered for those Algonk, the GBA views Algonk Level C LOA certificates). And the configuration decision as mapping to the GBA Medium LOA. complications increase as more BCAs Conversely, according to the policy become involved. It is therefore recommended to explicitly state the browsers. validation service’s acceptable certificate For proper policy OID representation, one of policy set—and not include the phrase “or following two items must occur: equivalent”—and use only the corresponding trust anchor. • The new CR must assert all policy OIDs of all subordinated CAs, or In practice, such asymmetrical mappings can be easily avoided. Both parties should • The end-entity certificates of the explicitly state and agree on how each of subordinated CAs must be re-issued the applicant’s LOAs relates to the issuing to include the new CR policy OID party’s LOAs. Continuing with our example, Figure 3 depicts one phase of the proposed when applying for cross-certification, the hierarchy. Assume the GBA has previously State of Algonk should explicitly request that cross-certified with one of the commercial the GBA PA map Algonk’s Level C LOA to vendor’s CAs (CVCA). The root CVCA has GBA’s Medium LOA. issued a proper subordinate CA A1, and A1 issues only special-audience end-entity Post-Issuance CA certificates. These end-entity certificates, Subordination when processed through the certificate mappings in the GBA/CVCA cross- One technique for reducing the number of certificate, map to a GBA Medium LOA. certificate bridges is to establish one root Assume the common root, CR, was under which all other certificates are issued. subsequently cross-certified with the GBA. Recently, there have been discussions of establishing such a common root (CR) that Then, in the final phase, the proposed would subordinate existing commercial CAs technique for demonstrating that A1 that meet government requirements. qualifies as a Scrutinized Provider is for the CR to subordinate the CA A1. In practice, A common root would also offer the this would result in a new subordinate CA advantage of needing to distribute only one A1*. A1 and A1* have the same public key self-signed public key in popular web and subject DN (to validate the already- CR GBA CVCA A1* A1 Figure 3: Subordinating Operational CA A1 existing end-entity certificates issued by A1), A popular misconception in writing system but different issuer DNs. This results in two security plans (SSPs) is that when a BCA is possible trust paths from the CR root to the cross-certified with the root CA of a A1-issued certificate: certificate issuer hierarchy, the BCA PMO is required to see only the C&A report • One directly from the CR through the corresponding to the remote organization's subordinated A1* CA certificate, and root CA, and that organization can be • The second from the CR through the trusted to silently perform C&As on their CR/GBA cross-certificate, through internal hierarchy. However, a careful the GBA/CVCA cross-certificate, and review of NIST Special Publication (SP) finally through A1 800-37, "Guide for the Security Certification When processed through the second trust and Accreditation of Federal Information path, the policy mappings in the cross- Systems," reveals more stringent certificates will ensure the end-entity requirements. policies are properly mapped into the CR's SP 800-37 defines a certification agent as certificate policy OID space. However, in "an individual, group, or organization direct trust hierarchies, such as from CR responsible for conducting a security through A1* to the end-entity certificate, no certification, or comprehensive assessment policy mappings can take place. Therefore, of the management, operational, and A1-issued certificates must include two sets technical security controls in an information of certificate policy OIDs—one set for the system to determine the extent to which the CR policy name space, and the other set for controls are implemented correctly, the CVCA policy OID space—thus reflecting operating as intended, and producing the A1's two superiors. desired outcome with respect to meeting the Interestingly enough, if a relying party were security requirements for the system." given just the CR root, the subordinated A1* (p.15) Additionally, SP 800-37 states that CA certificate issued by the CR root, and an since the certification agent "provides an end-entity certificate issued by CA A1, the independent assessment of the system relying party would find a perfectly valid security plan to ensure the plan provides a hierarchical issuance path from the CR to set of security controls for the information the end-entity cert. However, if CVCA system that is adequate to meet all revoked A1 (say, due to a compromise of applicable security requirements," the A1's private key), and the organization certification agent needs to be independent behind CVCA did not notify the GBA from: Program Management Office (PMO), then • "persons directly responsible for the the above direct trust path through A1* development of the information would still appear valid when, in reality, it system and the day-to-day operation should be declared as “revoked.” of the system" Therefore, extreme caution should be used • "individuals responsible for if such a "two master" topology is used. correcting security deficiencies identified during the security Operations Policies certification" Typically, one focuses on technical and Given a certification agent's independence policy issues within one's own security from the managerial and operational chains domain. In this section we consider of a CA, the resulting report cannot remain operations policies requirements such as solely within the organizations chain of Security Certification and Accreditation command—the report must be delivered (C&A). externally. The organization most interested in and most impacted by such a report is the BCA PMO, and therefore should be the recipient of the certification report. Therefore, the PMO of each BCA should regularly see the C&As of every issuing CA to which the BCA can form a trust chain. Conclusions As we have discussed, "bridging" for PKI interoperability is not the panacea that many thought it to be. It is extremely complex and requires careful attention to detail. It is easy to structure unintended and difficult-to- detect consequences. Such complexity often results in significant opportunities for undetected errors that the security community often points out as exploitable vulnerabilities. We also implore each organization to consider these inherent issues when performing security C&A and Certificate Policy/Certification Practice Statement (CP/CPS) Compliance Audits. References NIST Special Publication (SP) 800-37, “Guide for the Security Certification and Accreditation of Federal Information Systems” [http://csrc.nist.gov/publications/nistpubs/800- 37/SP800-37-final.pdf] RFC3280: “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” [http://www.ietf.org/rfc/rfc3280.txt] Side-Effects of Cross-Certification April 20, 2005 James L. Fisher, Ph.D. ControlNumber 2 Purpose  Help the inexperienced to wisely avoid pitfalls discovered (and imagined) by others  Motivate the savvy thinkers to advance fixes to help certificate bridge environments progress to the next level of maturity  Give insight into how certain technical decisions impact operational capabilities and/or legal standing if ($my->glass >= 0.5*$full) then { $quote= “Good advice is something a man gives when he is too old to set a bad example. -- La Rouchefoucauld”; } else { $quote= “It may be that your whole purpose in life is simply to serve as a warning to others.”; } ControlNumber 3 Topics To Be Covered  X.500/LDAP certificate directory implementation and interoperability requirements  Transitive and asymmetrical trust  Choosing the proper trust anchor  Cross-certificate policy mappings  Certification & Accreditation requirements ControlNumber 4 Benefits of Certificate Bridges  Allows the relying party to enjoy the efforts and benefits of a larger trust domain while not being required to be an integral part of that domain’s certificate hierarchy… – …while trusting one trust anchor—a public key within your own trust domain  An issued cross-certificate is a tangible representation of trust (and a declaration you accept their CP/CPS)  A trust path (including cross-certificates spanning the issuer’s and relying party’s domains), in part, forms a tangible record of trust storable for: – Future evidence of due diligence – Meeting institutional archival requirements – Satisfying NARA requirements? ControlNumber 5 Bridge Certificate Authorities (BCAs) Establish Border Directories  Border directories: – For publishing CA certificates, cross-certificates, and CRLs [OCSP coming soon] – (For publishing encryption certificates, but typically not signing certificates), and…  For facilitating trust path discovery and validation, by providing: – Chaining to, or referrals to, directories of all other CAs to which cross-certificates have been issued – A one-stop-shop virtual directory for use by local population for retrieving all relevant certificates and CRLs else might not know where to look • DN formatted CRLs? No AIA or SKI fields? ControlNumber 6 Certificate Directory Interoperability: The (Fictitious) Players  A government (Certification) bridge authority (GBA)  A government institution (GI)  A neighboring nation bridge authority (NNBA)  A university bridge authority (UBA)  An older, legacy PKI system at Enormous State Univ (ESU1)  A newer PKI system at the same university (ESU2)  A world-wide council (WWC)  A random transoceanic nation (RTN) ControlNumber 7 Certificate Directory Interoperability GI GBA NNBA WWC UBA RTN ESU1 ESU2 Legend: Purposeful trust path vs. possibly unintended trust path? ControlNumber 8 Directory Configurations Required for Trust Path Discovery/Validation NNBA c=NN GBA c=US cref(c=NN) cref(dc=int) cref(c=RTN) cref(dc=edu) subref(ESU Prov) o=Upr Govt o=edu subref(ou=GI) subref(ou=UBA) GI UBA ou=GI, o=Upr Govt, c=US o=edu, c=US dc=edu cref(o=ESU Prov, c=US) ou=UBA subref(ou=ESU Prov, c=us, dc=esu) ESU o=ESU Prov, c=US ou=ESU Prov, c=us, dc=esu, dc=edu ControlNumber 9 Directory Configuration for Interoperability: Lessons Learned  Each border directory needs to support superior references, subordinate references, cross references; configuration is complicated – MS AD does not support all necessary knowledge references  A BCA directory must be able to resolve (directly or indirectly) any base DN that could ever form a trust path through that BCA – e.g., GBA must be able to retrieve ESU dir entries  A “root” directory must include a knowledge reference for any “root base DN” that could ever form a trust path through it, even though that root directory did not directly cross certify with it – e.g., GBA must include a knowledge reference for c=RTN ControlNumber 10 Design Alternatives?  BCA directory returns referrals to only those directory with which it is directly cross-certified – But many LDAP clients still cannot process referrals – Trust paths traversing multiple bridges not discoverable if only DN-formatted certificate fields – All certificates must have properly formatted AIA fields • One missing or improperly formatted AIA field destroys ability to discover trust path – Dependency on SKI fields constrains path discovery from issuer to relying party  Use DC naming & have special DNS type/entry pointing to enterprise’s border directory ControlNumber 11 Transitive Trust  Cross-certification breeds phenomenon of transitive trust – Such indirect trust may or may not be intended or welcome • Example 1: GI ↔ GBA ↔ NNBA ↔ WWC ↔ RTN  Example 2: Country of Forbiddenstan (c=FB) cross-certifies with WWC…creating (unlawful) trust path back to GI – GI directors prefer there be no valid certificate trust path between GI and Forbiddenstan – Other agencies (humanitarian-oriented) have legitimate needs to trust Forbiddenstan-signed documents – Nation-wide filter might not be appropriate ControlNumber 12 Transitive Trust Scenario: Policy or Design Alternatives?  If rely only on chaining, somebody has to reissue cross- certificates with name constraints or path length constraints  GI re-issues cross-cert to GBA with name constraints – Probably become aware of need only after offense – Cross-certificate re-issuance has costs – Other relying parties need to be aware of this political situation and issue appropriate name constraints – Difficult to envision all necessary path constraint needs (path permitting or path inhibiting) before issuance – Revocation of original cross-certs affects pre-cache systems  GBA re-issues cross-cert with path length constraint and “special need” agencies cross-certify directly WWC – Might squelch longer, acceptable domestic-based trust paths? ControlNumber 13 Choosing the Proper Trust Anchor and Filtering Certificate Policies  Scenario: validation service provider in a multiple cross- certificate environment…which trust anchor? – (Typically chose trust anchor within your own certificate issuance domain) – Acceptable certificate policies: expressed in trust anchor’s policy OID space • Policy mappings in cross-certificates “translate” levels of assurances (LOAs)  Complicating factors: – Asymmetrical policy mappings – Possibility of multiple trust paths – Unidirectional cross-certifications ControlNumber 14 Choosing the Proper Trust Anchor… (Cont.) Policy mappings: (issuerDomain~subjectDomain) Medium~B GBA Algonk C~Medium LOAs: LOAs…from one CA!!!: Large Level D Medium Level C Small Level B Level A ControlNumber 15 Choosing the Proper Trust Anchor: Alternatives?  Is asymmetrical policy mapping necessarily undesirable? – Might be useful in certain environments – If undesirable, both parties should explicitly state and agree upon how each of the applicant’s LOAs relates to the issuing party’s LOAs  Should explicitly state the validation service’s acceptable certificate policy set—and not include the phrase “or equivalent”—and use only the corresponding trust anchor ControlNumber 16 Post-Issuance CA Subordination CR GBA CV  Adv: CR need to ship only one cert in web browser A1* A1  CR subordinates A1 to demonstrate approval/membership  EEC must have (or be re-issued to include) new CR policy OID –or– new CR asserts policy OIDS of all subordinated CAs; careful policy mappings  Two possible trust paths  Revocation of A1 requires manual notification of CR PMO ControlNumber 17 Operations Policies  Popular misconception: when a BCA is cross-certified with the root CA of a certificate issuer hierarchy, the BCA PMO is required to see only the C&A report corresponding to the remote organization’s root CA, and that organization can be trusted to silently perform C&As on their internal hierarchy – True only for low assurance systems [800-37, 3/2005]  Reality: certification agent needs to be independent of developers, sys admins, anyone responsible for correcting security deficiencies found – Resulting report must be delivered externally (e.g. the BCA PMO)  Impact: the PMO of each BCA should regularly see the C&A of every issuing CA to which the BCA can form a trust chain ControlNumber 18 Evaluating the Performance Impact of PKI on BGP Security Meiyuan Zhao∗and Sean W. Smith Department of Computer Science Dartmouth College David M. Nicol Department of Electrical and Computer Engineering University of Illinois at Urbana-Champaign February 2005 Abstract among parties spanning a large set of domains, these se- curity mechanisms typically rely on public key cryptog- The Border Gateway Protocol is central to making the In- raphy. Implicitly or explicitly, public key infrastructure ternet work. However, because it relies on routers from thus also becomes a critical component—otherwise, how many organizations believing and passing along informa- do the parties know what public keys to use and whether tion they receive, it is vulnerable to many security at- they are still valid? tacks. Approaches to securing BGP typically rely on pub- Neither public key cryptography nor public key infras- lic key cryptography, in various encodings, to mitigate tructure come for free. However, when designing and an- these risks; to work in practice, these approaches usually alyzing these large information-distribution systems, it’s require public key infrastructure. This cryptography and easy to overlook these implementation details, and the the PKI may both potentially impact the performance of performance impact they can have on the overall proto- this security scheme; however, evaluating how these ef- col. Furthermore, given the large, messy nature of Inter- fects may scale to large networks is difficult to do analyt- net routing, it can be hard to evaluate this impact: analytic ically or empirically. techniques may fail to capture the complexity, and empir- In this paper, we use the tools of simulation to evalu- ical techniques may require a prohibitively large testbed. ate the impact that signatures, verification, and certificate In previous work [27], we used the tools of parallel handling have on convergence time, message size, and simulation to evaluate the performance impact of basic storage, for the principal approaches to securing BGP. signing and verification on route attestations—and pro- posed and evaluated an improved way of generating and encoding this information. In this paper, we extend this 1 Introduction work: By distributing and maintaining routing information, the • to consider two new aspects of performance: mes- Border Gateway Protocol (BGP) [32, 39] plays a central sage size and memory cost; role in making the Internet work. However, BGP relies • to consider the PKI impact of recent proposals for on hearsay information. BGP speakers trust the messages in-band origin authentication; they receive and they completely trust other BGP speak- ers to follow the protocol specification reliably. Conse- • to consider the performance impact of standard PKI quently, BGP—and the Internet it routes—is vulnerable to revocation schemes; and many potential attacks by malicious players [26]. To miti- gate these risks, many researchers have proposed security • to consider the potential improvement of using re- mechanisms to authenticate the routing information trans- cent aggregate signature schemes in place of stan- ferred between BGP speakers [1, 8, 13, 17, 35, 40, 41]. dard signatures in assertion chains. S-BGP is the dominant scheme here. We find that among the half dozen techniques studied Because of the need to authenticate information passed there is no clear best solution. Compared to the technique ∗ contact author, zhaom@cs.dartmouth.edu that uses the least memory, the technique that supports the fastest convergence time is three times faster but uses plicit route withdrawal, decides whether it prefers the new twice the memory. Signing cost is what matters for speed route. A withdrawal can also be an explicit announce- (and BGP convergence) but this comes at a price, memory ment, with no mention of an alternative preferred route. and message size. In this case, the recipient may examine the previously re- This Paper Section 2 reviews BGP and S-BGP. Sec- ceived routes to the same prefix and decide whether there tion 3 reviews some alternate encoding and cryptographic is an alternative to announce to its peers. If no such route approaches. Section 4 presents our evaluation methodol- found at hand, it simply withdraws the route as well. ogy. Section 5 presents our experiments and results for BGP rate-limits the sending of Update messages with path authentication. Section 6 presents our experiments parameter called the Minimum Route Advertisement In- and results for origin authentication. Section 7 reviews re- terval (MRAI), which is basically the minimum amount lated work, and Section 8 concludes with some thoughts of time that must elapse between successive batches of for future research. Updates sent to a neighbor. BGP speakers have output buffers to keep waiting Update messages, and send them in batches when reaching the MRAI. A speaker may have a different MRAI for each of its peers or may have one 2 BGP and S-BGP MRAI that controls all peers. In practice, throughout the Internet, the default value the MRAI is 30 seconds. The Border Gateway Protocol (BGP) [32, 39] is the rout- Any change of network reachability will be reflected ing protocol for maintaining connectivity between au- in the routing table of some BGP speaker. BGP will tonomous systems (ASes) in the Internet. Each AS is then propagate this change via Update messages through assigned a unique integer as its identifier, known as its the entire network, like a wave. The convergence time AS number. An AS manages subnetworks expressed as measures the length of time for such wave of announce- IP prefixes—a range of IP addresses. A BGP speaker— ments to die out completely—in other words, for the net- a router executing BGP protocol—constructs and main- work to return to a stable state. During the transient pe- tains forwarding tables that enable packet forwarding. riod of convergence, the continual changing of preferred A BGP speaker maintains connections with neighboring routes degrades the effectiveness of packet forwarding. speakers, known as its peers, and sends an Update to an- Longer convergence times thus reflect increased network nounce a new preferred route to prefix p. The route is instability and may cause severe network performance a (prefix, AS path) tuple. The AS path is a sequence problems. Studies of BGP have considered convergence of AS numbers that specifies a sequence of autonomous [10, 20, 34] and possible optimizations to control and ac- systems through which one can traverse the network; last celerate it [11, 19, 21, 23, 30, 38]. AS in the sequence is the originator of this route. For in- stance, if the autonomous system ASk owns IP prefix p, Because BGP is central to Internet functionality and is the autonomous system AS0 might send out an Update vulnerable to malicious actors, we need to secure the in- (p, {AS0 , AS1 , . . . ASk }) to announce its preferred route to formation that BGP distributes. We consider each compo- p. Each BGP speaker keeps received routes in its rout- nent: ing table; for each prefix, the speaker tags one route as its • Origin authentication considers whether the origi- preferred one. nating AS really controls a claimed IP address range. Typically, a speaker’s routing table changes when it adds a new route, deletes a preferred route, or replaces a • Path authentication considers whether a claimed previously preferred route with a new one. BGP speakers path to reach some IP prefix is in fact valid. incrementally send Update messages to announce such changes to their peers. When speakers establish (or re- The dominant security solution, Secure BGP (S- establish) a BGP session, they share their own routing ta- BGP) [17] focuses on the Update messages. The first step ble with each other via a large number of Update mes- of S-BGP is to set up public key infrastructures to help sages announcing routes in their routing tables. If it re- establish the authenticity of the involved parties. S-BGP sults in new preferred routes, processing of an Update uses X.509 [12] public key certificates and puts BGP- message may create a number of new Updates. If the related information into certificate extensions. Speak- speaker chooses to announce a new preferred route, it ex- ers digitally sign the Update messages they announce to tends the existing AS path by perpending its AS num- peers; with these X.509 certificates, recipients can verify ber to it and sends it to all of its peers, except the one the signatures to authenticate the received routes. who sent the route earlier. When a speaker announces More specifically, each speaker uses address attesta- a route to prefix p, it implicitly withdraws the last route tions (AAs) for origin authentication, and route attesta- it announced to p. The recipient, understanding this im- tions (RAs) for path authentication. ICANN ASes, and BGP speakers. The AS number authentication is similar to address allocation authentication. At the top, APNIC ARIN RIPE . . . AT&T ICANN assigns AS numbers to RIRs. Then, each RIR assigns some of its AS numbers and issues certificates to the third tier organizations (also called AS owners). These MCI GTE−1 . . . DSP1 AT&T Data . . . Sub1 AS owners, in turn, issue certificates for authenticated ASes. AS owners also issue certificates for BGP speaker; Sub2 DSP2 Sub3 each such certificate binds the router name to an AS num- ber and router ID, testifying that the speaker belongs to certain AS. Typical certification paths in AS number and Sub4 ... Subk BGP speaker identification PKI are as follows: ICANN “ICANN→Registry→AS owners→AS numbers” “ICANN→Registry→ISP/DSP. . . →BGP speakers”. APNIC ARIN RIPE LACNIC 2.2 S-BGP Attestations Org1, AS#s .... .... OrgK, AS#s As noted earlier, S-BGP uses two forms of attestations. ... For origin authentication, an address attestation (AA) (AS, AS#) .... (AS, AS#) establishes that an AS (the subject in the AA) is autho- rized by an organization Org x (the signer of the AA) to (Rtr, AS#, RtrID) .... (Rtr, AS#, RtrID) announce certain IP blocks of address space [17]. The origin AS sends the AA together with a certificate that Figure 1: Sketch of the S-BGP PKIs. authorizes that Org x in fact owns that IP address block. Hence, the receiver of the Update message is able to val- idate the certificate and verify the signature in this AA. 2.1 S-BGP PKIs For path authentication, a route attestation (RA) is signed by a BGP speaker to authenticate the existence and To enable validation of attestations, S-BGP proposes two position of an AS number in an AS path [17]. Figure 2 X.509 public key infrastructures. The first PKI contains demonstrates the structure of RAs. Such attestation is certificates to authenticate the owners of portions of the nested: each BGP speaker signs the AS path in sequence, IP address space. The second PKI is to authenticate BGP as it joins. That is, first the origin BGP speaker signs the speakers, ASes, and the owners of ASes. Figure 1 illus- AS number of the origin autonomous system and the in- trates the structures of these PKIs. Both PKIs are hier- tended receiver (in the form of AS number). The next archies rooted at ICANN [15]. ICANN issues itself self- signer is the receiver of this RA; it computes and signs signed certificates and further issues certificates to the the first tier of organizations, typically Regional Internet Reg- istries (RIRs) such as ARIN, RIPE, APNIC, and LACNIC. p, {3, 2, 1} p, {2, 1} S1 For the address allocation PKI, ICANN issues itself a certificate claiming the ownership of entire IP address p, {1} S1 S2 space on the Internet. Consequently, it issues certificates S 1 = {1, p, 2}K1 S 2 = {2, p, 3, S 1 }K2 S 3 = {3, p, 4, S 2 }K3 to RIRs as it assigns IP address blocks to them. The cer- 1 2 3 4 tificate contains an extension that specifies the set of ad- dress blocks ICANN is allocating to that RIR. Each RIR Figure 2: This figure sketches the process of sending route an- further assigns portions of its address blocks and issues nouncements and their route attestations. We have four ASes corresponding certificates to the third tier organizations numbered as 1, 2, 3, and 4. AS 1 initiates the process by send- of the hierarchy. The process continues until it reaches ing announcement (p, {1}) stating that it owns prefix p and it end subscribers. A typical certification path for an address is reachable. It generates the corresponding route attestation by block is similar to the following: signing {1, p, 2} using its private key K1 . It puts its AS num- “ICANN→Registry→ISP/DSP. . . →Subscribers”. ber first, then the prefix, then the intended recipient. The other ASes continue this process, except that they glue new informa- The second PKI contains certificates for AS number as- tion to the previous attestation sign the resulting blob. The figure signments, as well as identity certificates of organizations, shows the AS path components in bold. p, {3, 1} Researchers have introduced a number of optimizations for S-BGP [16], mainly focusing on caching signed and S 1 = {1, p, 2}K1 verified routes and applying DSA pre-computation. These S 30 = {3, p, 4, S 1 }K3 optimizations reduce the computational cost related to cryptographic operations in the cost of extra memory cost and computation complexity. 3 4 Figure 3: This figure sketches how S-BGP would stop an at- 3 Alternate Signature Approaches tempt by AS 3 to forge a route announcement. AS 1 had told AS 2 it would accept messages to p, and AS 2 told that to AS 3. Besides caching, other studies suggest different crypto- However, AS 3 is trying to strip away 2 and fool AS 4 into be- graphic schemes that may potentially reduce the overhead lieving a fraudulent 2-hop route. However, since AS 1 included of S-BGP route announcement authentication. We discuss the name of AS 2 in its signed statement about that link, AS 4 three: signature amortization, sequential aggregate signa- will detect the forgery. tures, and origin authentication. the concatenation of the previous RA, the newly appended 3.1 Signature Amortization AS number, and intended receiver. The process goes on until the entire AS path is signed. In our previous analysis [27], we proposed Signature The inclusion of the intended recipient and the prefix Amortization (S-A). in each signature is necessary to prevent against “cut-and- Looking at the details of the path authentication pro- paste” attacks. To continue the earlier example, consider cess, we observed two important facts. First, BGP speak- Figure 3. AS 3 is not able use the attestations it has re- ers verify RAs more often than creating RAs themselves. ceived to forge an attestation for route (p, {1,3}) that AS Hence, making verification faster could potentially de- 4 will accept. To do so, AS 3 would need a signed state- crease the overall computational latency. Second, when ment from AS 1 offering to route information to p directly the BGP speaker sends identical routes to its neighbors, it from AS 3. However, the signed link that AS 3 has from has to create distinct RAs; moreover, BGP speakers keep AS 1 explicitly specifies that AS 1 links to AS 2, not AS outgoing Update messages in buffers and, using MRAI 3. To facilitate validation, BGP speakers send the new timers, send them in bulk. This bulk send creates the po- RA together with all the nested RAs associated with it. tential for getting more “bang” from each private key op- This way, the receiver can authenticate the entire AS path. eration. However, receivers need certificates for BGP speakers to Our S-A scheme exploits these two facts. To speed up validate these signatures. the verification processing, we use RSA, since RSA veri- fication is significantly faster than DSA (used by S-BGP). 2.3 Performance Issues of Path Authentica- Then, we amortize the cost of signing operation in two steps. tion In step one, when a BGP speaker sends the same route Several factors affect the performance of path authentica- announcement to multiple recipients, we collapse it to lit- tion in S-BGP, given the structural properties of RAs. erally the same announcement—using a bit vector (or a First, BGP speakers consume extra CPU cycles when more space-efficient equivalent) to express which of the signing and verifying RAs and when handling and validat- speaker’s peers are the recipients. Thus, the speaker only ing certificates. Each Update message involves one sign- needs to generate one signature, instead of one for each re- ing operation by each signer and k verification operations cipient; the verifier of this RA uses the bit vector to check by each verifier (where k is the number of RAs for this AS the intended receiver. To do this, the speaker needs to pre- path). Moreover, for each signature verified, the verifier establish an ordered list of its neighbors, and distribute needs to validate the certificate of the alleged signer. Sec- this to potential verifiers; however, we can put this infor- ond, RAs and certificates increases message size. Each mation in the speaker’s X.509 certificate, since the verifier message with an AS path of length k carries k nested RAs. needs to obtain that anyway to verify the signature itself. Finally, to decrease the number of signing/verification op- In step two, when its MRAI timer fires and a BGP erations, one could cache the signed or/and verified routes speaker sends the messages accumulated in its out buffers, in memory. Therefore, memory cost becomes another is- we have it collect all “unsigned” messages, build a Merkle sue. hash tree [24, 25] on them, and signs the root of the tree— thus generating one signature for all unsigned messages, In the Aiello OA scheme, the BGP speakers send or- instead of one for each. A leaf of the tree is the hash of the dinary BGP Update messages together with origin au- pair of a route and its recipients. The resulting RA con- thentication tags (OATs). Each OAT contains a delegation sists of the RSA signature on the root, the the hash path path, a set of delegation attestations (one for each edge in from the root to that leaf, the route, and the recipient bit the path) and an ASN ownership proof. The structure of vector. A verifier of the RA can use these hash values and a delegation attestation is similar to an S-BGP address al- information in the route announcement to construct the location certificate. The signer authorizes that the subject root of the tree correctly. There are trade-offs, however. is delegated some address blocks as recorded in an exten- The verifier needs to perform a few extra hashing opera- sion. The ASN ownership proof is a certificate issued by tions when verifying a RA, and the message size grows ICANN; it attests that some AS numbers are granted to a (due to the hash path). particular organization. With our S-A approach, we speed up the security oper- The OA scheme considered four possible constructions ations of S-BGP at the cost of more memory and longer on delegation attestation. A Simple Delegation Attesta- Update messages. tion contains a signature by an organization on a tuple (p, org), where p is the prefix delegated to org. An Authen- tication Delegation List combines all (p, org) tuples by 3.2 Sequential Aggregate Signatures the same organization into single list and generates one signature. A compromise of these two approaches, an Recently, aggregate signature schemes have emerged that AS Authentication Delegation List breaks up the long list save signature space when multiple parties need to sign into several sublists (each containing the delegation tuples messages [2, 3]. The sequential aggregate signature specifying the address delegations made to the same or- (SAS) scheme by Lysyanskaya et al. [22] combines n sig- ganization and autonomous system) and signing each. An natures from n different signers on n different messages Authentication Delegation Tree constructs a Merkle hash into one signature of unit length. In SAS, each signer, in tree on an organization’s delegation list, and signs the root an ordered sequence, incrementally signs its new message of the tree. We denote these variations by the terms OA- and incorporates it into the aggregate signature σ. A party Simple, OA-List, OA-AS-List, and OA-Tree, respectively. with knowledge of the n messages, the public keys of the n ordered signers, and the final σ is able to verify that each signer si has correctly signed his message Mi and σ 4 Evaluation Methodology is a valid sequential aggregate signature. The major ad- vantage is that the signature of n messages is the same asAs Section 1 notes, this paper reports research examining the length of an ordinary signature. Furthermore, an SAS the performance impact of public key cryptography and scheme can be built from RSA, with small modifications, public key infrastructure on BGP security. Section 4.1 easing implementation. describes the metrics we use. Section 4.2 describes the Applying SAS scheme to path authentication of S-BGP, various BGP security approaches on which we take these we generate σ along the AS path similar to nested RA measurements. Section 4.3 discusses the tools we use to signatures. Since one aggregate signature is enough to carry out these experiments. authenticate entire AS path, this scheme shortens message size. 4.1 Performance Metrics 3.3 Origin Authentication We use a set of metrics to evaluate performance in terms of time and space. Aiello et al. [1] consider the semantics, design, and For time, we measure the number of cryptographic op- costs of origin authentication in BGP, and propose an OA erations involved, the resulting CPU cycles, and the BGP scheme. convergence time: the time it takes the system to re- The authors formalize semantics for IP address dele- achieve a stable state after a perturbation, such as a new gation, which is similar to the address allocation PKI by route announcement, a route withdrawal, or a router re- S-BGP. The proofs of the IP address ownership establish boot. For each security scheme, we compare its con- a tree-like hierarchy rooted at IANA [14]. The next tier vergence time with convergence time that original BGP are the organizations that receives /8 IPv4 address blocks achieves for the same perturbation. (Given the distributed directly from IANA. These organizations further delegate nature of BGP, convergence time is very difficult to be sub-block addresses; delegations continue until we reach predicted using analytical techniques.) autonomous systems. For space, we measure both the message size and the storage cost in memory. Similar to other studies, our ex- Convergence Message Size Memory periments relax the current BGP maximum transfer unit S-BGP long moderate best (MTU) (4096 bytes) limitation, to be able to understand S-A shortest worst worst the efficacy of any possible optimization. SAS longest best best Table 2: Performance rankings for the path authentication 4.2 Experimental Approaches schemes we examined Our previous work evaluated the time impact of S-BGP and S-A on path authentication. We now measure the its peers, via a large amount of route announcements. To space impact as well, and both space and time impacts of maximize the effects, we let the rebooting BGP speaker to SAS on path authentication. We measure the time impact be the one with the most peers. of CRL and OCSP revocation schemes on fully optimized Besides the common settings, we also have specific S-BGP. parameters for each of the security schemes. Table 1 We also examine the origin authentication scheme of summarizes the benchmarks and measurement numbers Aiello et al. We measure time and space impacts of all we use in our simulation. The running time benchmarks four variations, as well as the time impact of CRL and of cryptographic operations are from OpenSSL [29] li- OCSP revocation on the OA-AS-List variation (since it’s brary. For those algorithms not directly implemented by the closest to S-BGP origin authentication). the library (such as DSA pre-computation, SAS aggre- gate signing and SAS aggregate verification), we decom- pose the involved operations and sum up the benchmarks 4.3 Simulation of each step as an estimation. In addition, the numbers are normalized to a 200MHz CPU, which is a common We use discrete-event simulation to understand the perfor- CPU speed of BGP routers. We use a real system to mea- mance of BGP origin and path authentication schemes in sure and estimate latencies of processing plain Update a large-scale environment. As with our earlier work, our messages, of sending a OCSP request and receiving a re- experiments uses SSFNet [5, 28], a discrete-event simu- sponse, and of fetching CRLs. To take into account other lator that provides a comprehensive model of basic BGP factors that could potentially affect the numbers, the simu- operations [31]. Our earlier work added hooks for variants lation decides these values by uniform distribution within of processing models of BGP security schemes [27]. certain ranges. S-BGP studies [16, 18] give the numbers Throughout this study, we evaluate security schemes in for sizes of S-BGP certificate and attestations. the same network topology and same BGP activity set- tings. We use a 110-AS topology, with one operating BGP speaker per AS. For modeling simplicity, each BGP 5 Path Authentication Performance speaker announces two prefixes. In our model, each AS also possesses virtual BGP speakers that don’t actually Analysis run a simulated BGP protocol. We use the number of such BGP speakers to represent the size of an AS; its size af- We compare performance impact of S-BGP, S-A, and fects the time it takes for one Update message to be prop- SAS. We examine the performance on signatures and agated through an AS. PKIs respectively. This section gives detailed results and analysis. We use the public data provided by RouteViews project [33] to generate a graph of AS connectivity of the Internet, then reduce the size to 110 ASes using a col- 5.1 Signatures and Verifications lapsing procedure. This reduced graph still preserves cer- tain macroscopic properties [6] seen on the entire Internet. Before examining details, we enumerate our major find- Moreover, we incorporate our estimation of route filtering ings on convergence time, message size, and memory cost policies into the topology using a method, similar to the in Table 2. S-BGP performs badly on convergence time, one proposed in [7]. but is fairly efficient on memory cost. S-A outperforms During normal BGP activities, we let one BGP speaker the other two on convergence time, but is significantly crash and reboot. We evaluate the performance of the en- more costly than the other two schemes on message size tire system during router rebooting process. The work- and memory cost. SAS generates the shortest Update load on BGP speakers could be much higher than normal messages, but results in the longest convergence time. BGP activities, since the rebooting BGP speaker receives We also studied the efficacy of strategies for caching routing table dumps in a short period of time from each validated (or generated) signatures. In simulation experi- SHA-1 hash MD5 hash Attestation S-BGP X.509 Certificate Identifier Length (bytes) 20 16 110 600 4 RSA DSA DSA (p-c) SAS Verify Time (ms) 2.5 31.0 31.0 2.5 Sign Time (ms) 50.0 25.5 0.015 50.0 Signature Length (bytes) 128 40 40 128 OCSP request CRL fetching Operation Latency (second) 0.5–1.0 0.5–1.0 Table 1: Constants and benchmarks used for simulation. RSA, DSA, and SAS algorithms are based on 1024-bit keys. ments, we explored S-BGP with several variations of DSA including signing, verification, and hashing (“crypto,” optimizations. For the presentation of experiment results, in Figure 6). SAS requires 1723.2 seconds extra time we use cDSA to denote S-BGP with caching, pDSA to for aggregate signing and aggregate verification, which is denote S-BGP using DSA pre-computation, and cpDSA much shorter than 4002.2 seconds by S-BGP. This dif- for S-BGP with both optimizations. In our model, these ference results mainly because aggregate verifications are caching strategies store both validated signatures and gen- much faster than DSA verifications. Caching optimization erated signatures; we use 10µs (with a uniformly dis- to S-BGP and SAS scheme can significantly reduce total tributed delta of 5µs) to model the lookup time. The S-A CPU time. Although S-BGP (pDSA) uses much faster scheme will not speed up by caching hash trees with sig- signing operations, the net speed-up is limited, because natures, because the trees, and hence the signatures, are the number of verification operations dominates the num- constantly changing even for the same route announce- ber of signing operations. Compared with S-BGP and ment (since the trees depend on the context of what else is SAS, S-A improves both aspects—fewer signing opera- being signed at that time). Therefore, we only examined tions and faster verifications. Our experiments confirm it S-A scheme without caching, when studying processing is the most efficient on CPU cycles. latency and convergence time. However, we model a spe- Next, we look at convergence time. Among the three cial variation for S-A caching merely to understand po- major schemes, SAS is the worst. Compared with plain tential memory cost it might result. Finally, all the ex- BGP, it converges three times slower. S-BGP comes next, periment results are average numbers from 20 runs of the with a slowdown of about 2.3 times. Even with optimiza- simulation. The standard deviation is less than 5%. tions, S-BGP still takes 46.05% longer to converge. (Our previous work [27] showed better S-BGP numbers, but that turned out to be due to a bug in our simulation code.) Time We examine the convergence time by looking at Such slowdowns lead to routing fluctuations that create the counts of cryptographic operations. Figure 4 through all sorts of network problems, such as increased packet Figure 7 summarize the results. All the schemes without loss rates, increased network latencies, increased network caching optimization generate relatively the same number congestion, and even disconnections. In our experiments, of signature verifications, proportional to the total num- ber of AS numbers encountered in AS paths in route an- nouncements. Similarly, caching optimization by each of 120,000 the schemes achieves relatively the same number of sav- 110,923 112,201 101,947 111,449 ing percentage. 100,000 The story of signing operations remains the same for 80,000 S-BGP and SAS schemes. The S-A scheme can dramat- ically save as many as 98.3% of signing operations. Our 60,000 experiments show that the average hash tree size by S-A 40,000 is about 60.1, indicating that S-A is able to amortize the 24,826 33,216 24,181 cost of 60 signing operations into only one signing and a 20,000 few hashing operations. 0 The CPU cycles and convergence time reflect this dif- S-BGP S-BGP S-BGP S-BGP S-A SAS SAS ference in the number of cryptographic operations. We (DSA) (cDSA) (pDSA) (cpDSA) (caching) sum up the total CPU time on all BGP speakers, and also track the portion consumed by cryptographic operations, Figure 4: Verification operations in path authentication 25,000 700 22,072 22,465 22,303 600 20,000 500 Time (seconds) 15,000 400 11,862 11,522 12,035 300 10,000 200 5,000 100 350 0 BGP S-BGP S-BGP S-BGP S-BGP S-A SAS SAS 0 S-BGP S-BGP S-BGP S-BGP S-A SAS SAS (DSA) (cDSA) (pDSA) (cpDSA) (caching) (DSA) (cDSA) (pDSA) (cpDSA) (caching) Figure 7: Convergence time in path authentication Figure 5: Signing operations in path authentication Memory Figure 8 shows the average memory cost and maximum memory cost for individual BGP speakers. We router reboots by BGP even without any security protec- start with a baseline of 9KB memory at each speaker, for tion already cost the network 153.7 seconds to converge. plain BGP. On average, S-BGP increases this requirement Extending the period to another several minutes is not a to 112.25KB, SAS to 121.95KB, and S-A to 314.38KB. good option. We assume that BGP speakers record all cached routes Fortunately, our S-A scheme increases the convergence in memory (e.g., RAM). In the simulation, we count the only by a few seconds, with no burden on caching large bytes of the IP prefix, AS path, and related cryptographic amount of data in memory. data structures (signatures, hash values, and bit vectors). Our experiments revealed that, counter-intuitively, con- As mentioned earlier, frequent changes of hash trees vergence time is not proportional to the CPU time spent prevent S-A from saving processing latency by caching by BGP speakers. In fact, the data suggests that the la- signatures. To explore the memory impact of caching, tencies in the message sending process (therefore, sign- we tried letting S-A cache more stable data, the leaf in- ing overhead) could be the dominant factor. For instance, formation: Update messages, signatures, and associated if we consider only the CPU time consumed by signing bit vectors (assuming neighboring relationship between operations, SAS costs the most, about 92% of the total ASes stays unchanged during simulation). For this ex- CPU time, which could explain why SAS is the slow- periment, we dispensed with hash trees, but the resulting est on convergence. One might reach a similar conclu- convergence time of a variant that used hash trees and this sion from the inconsistency between S-BGP (cDSA) and caching would not be worse than the numbers shown in S-BGP (pDSA). Although S-BGP (pDSA) requires more Figure 7 and 8. CPU cycles, almost all of these CPU cycles are spent for One of the leading factors that affect this memory cost signature verifications. As the result, it converges faster. 450 Average 400 Maximum 4,500 350 314.38 Basic 300 4,000 Kilobytes Crypto 3,500 250 Time (seconds) 3,000 200 2,500 150 121.95 112.25 2,000 100 1,500 50 9.02 1,000 0 BGP S-BGP S-A (variant SAS 500 (cDSA) with caching) (caching) 0 BGP S-BGP S-BGP S-BGP S-BGP S-A SAS SAS (DSA) (cDSA) (pDSA) (cpDSA) (caching) Figure 8: Comparison of memory costs for caching. The S-A scheme in this comparison is a variant that does not use hash Figure 6: Total CPU time in path authentication trees, and caches leaf information instead of signatures. BGP S-BGP S-A SAS 5.2 Certificate Revocation Average message 36.09 318.61 1107.08 184.29 Bringing the PKI one step closer to reality requires con- size (bytes) sidering the costs of checking the validity of a signer’s Increase 8.83 21.57 5.11 certificate, when verifying a signature. Recall that BGP Maximum speakers use their private keys to sign and create RAs on message 42.6 527.7 1915.4 191.2 route announcements. We use simulation to model the size (bytes) case that BGP speakers validate BGP speakers’ public Increase 13.77 47.75 4.40 keys in certificates before using them to verify RAs. Table 3: Message size. The increase numbers are based on the In our revocation simulation, we assume that the 110 message size by original BGP. ASes belong to different organizations (also called PKI domains), with each organization having its own CA issu- ing certificates for that organization’s BGP speakers. Each PKI domain has a repository of certificates, offered by is signature length. Here, S-BGP outperforms S-A be- an LDAP server. When we model revocation by OCSP, cause a DSA signature is much shorter than a RSA signa- we assume an organization has an online OCSP respon- ture (e.g., 40 bytes vs. 128 bytes). Secondly, SAS is able der; when we model CRLs, we assume the organization’s to save memory by caching only one signature for an AS LDAP server also offers CRLs. path of any length. Even with RSA signatures, SAS is as We then examine the convergence time for S-BGP with efficient as S-BGP. all optimizations, using OCSP or CRLs for certificate val- Although not shown in Figure 8, edge routers consume idation. The OCSP approach provides fresh information the most memory for caching routes, statistically. We of certificate status, at the cost of network and process- posit two reasons. First, as a pure customer in the net- ing latencies. The CRL approach is less aggressive: the work, an edge router may receive more route announce- verifier downloads CRLs periodically, checks certificate ments than the ones in the core of the network. Sec- status with these local copies, and (when the local copies ond, and most importantly, the AS paths recorded by edge expire) get fresh CRLs from the appropriate repositories routers are significantly longer, so these routers will cache via the LDAP protocol. more signatures. For simplicity, we assume that BGP speakers can vali- In ongoing work, we are exploring using cryptographic date OCSP responses and fetched CRLs by verifying sig- hashing to further reduce cache size. natures on them. In other words, we do not model the process of discovering trust path for them. The rest of this section discusses and compares the performance impact that checking certificate status has on S-BGP. Update Message Size SAS produces one signature for an AS path; it wins the competition on message size. S- OCSP The model we use to study OCSP is close to typ- BGP is next, again, because of shorter signature length. ical PKI practice in the real world. In a practical PKI, one Our experiment results, shown in Table 3, confirm that S- or more OCSP responders connect to a certificate database A generates the longest messages. For both S-BGP and S- operated by local CAs to serve the status information of A, number of signatures in messages grows as the length the certificates issued by local CAs. Optionally, the re- of path increases. sponders can set up SSL connections to enhance privacy For SAS, since each Update message contains only one for the client. aggregate signature for the entire AS path, the maximum The OCSP response is a signed data structure that con- message size is close to the average size. On the other tains the real-time status of a requested certificate. OCSP hand, the longest Update message for the S-BGP and S-A introduces latencies, from setting up an SSL connection, schemes is about two times as long as average messages. from network delays, from real-time signing, and from Our experiments measured shorter message sizes than signature verification. According to measurements we the number measured in the Internet, because we only made with real-world OCSP implementations, the latency considered the fields (AS path, signatures, hashes, and bit of one round is about 0.5–1.0 seconds, the majority of vectors) that would vary between the schemes. Since the which is from network latency. ignored portions are the same for each of the schemes, the If a client has multiple certificates to validate, it can simulation still results in a fair comparison of the message send OCSP requests in sequence or in parallel. A proxy, size. such as a Certificate Arbitrator Module (CAM) [37], can Protocol # Ann. # Vrf. # Sign # OCSP Rqst. Basic CPU (s) Crypto CPU (s) Convergence (s) BGP 19571.8 – – – 1310.6 – 153.7 S-BGP (cpDSA) 21898.9 24180.6 11521.9 – 1464.1 755.4 224.4 Sequential OCSP 22542.9 113859.9 11663.2 89912.5 1501.7 70990.2 2720.4 Parallel OCSP 21707.8 110429.3 11290.5 87004.0 1448.5 3971.0 344.3 Table 4: Performance of validating certificates using OCSP for S-BGP path authentication contact multiple OCSP responders throughout the net- net using such semantics. Using publicly available Inter- work and send requests in parallel for the client. In our net measurements, these researchers generated an approx- simulation, we model both sequential and parallel cases. imated address delegation graph, a tree rooted at IANA. Table 4 shows that checking certificate status using The structure is very similar to the address allocation PKI OCSP for S-BGP is intolerably expensive. Sending se- by S-BGP (not surprising, since it essentially solves the quential OCSP requests is an especially bad idea. We put same problem). performance numbers of BGP and S-BGP (cpDSA) in the For each prefix in route announcements, the Update table for comparison, and show both the basic CPU time, message should carry an address delegation path for au- the processing latencies related to cryptographic opera- thentication. The scheme of Aiello et al. [1] uses in-band tions, the latencies by OCSP requests and responses, and address delegation attestations carried in Update mes- network latency in between. Even the resulting conver- sages, because these attestations are much smaller in size gence time for parallel OCSP requests is 344.3 seconds. than the S-BGP address allocation certificates. We use simulation to re-visit this issue. CRLs For CRLs, we assume that each BGP speaker has We model address delegation using this approximated a local cache of CRLs. Since signature verification re- complete graph of the Internet and size it down so that quires an up-to-date copy of the CRL from the relevant it is suitable for our 110-AS simulated network. In prac- CA, the BGP speaker pays the price of fetching and vali- tice, ASes could announce many prefixes, each of which dating fresh ones before verifying RAs, if some CRLs are could have its own address delegation path in the graph. missing or expired. Our simulation model is much simpler; each AS only an- nounces two prefixes. We add randomness in the model To evaluate the cost of fetching CRLs, we let BGP to capture the diversity of the real world. First, we put the speakers have a certain fraction of the CRLs in their local address delegation graph into the configuration of simu- cache be expired, and then measure the resulting conver- lation, so that BGP speakers can recognize all delegation gence time. The experiments assume that it costs 0.5–1.0 paths for each origin AS. Next, we let BGP speakers ran- seconds on average for BGP speakers to fetch a CRL. We domly choose a path for the prefix based on the origin AS. also assume that CRLs are valid for 12 hours. We limit the path length to seven (since address delegation Figure 9 shows the measurement data from simulation. paths are reported to be no longer than 4-5, in practice). It is clear that more expired CRLs cause the convergence times to increase linearly. These times range from 224.4 seconds to 287.7 seconds. Hence, even with all CRLs ex- 290 pired, validating certificates against CRLs is still a more convergence time (seconds) efficient approach than OCSP, which costs 344.3 seconds 280 to converge with the fast option, parallel OCSP requests. 270 260 6 Origin Authentication 250 Our approach to studying origin authentication is similar 240 to the approach we took for path authentication. We first 230 look at the performance impact of signatures and verifica- tions, then examine the certificate validation cost on top of 220 0 20 40 60 80 100 120 that. We add one model in simulation for experiments— Number of Expired CRLs the approximated address delegation graph. As mentioned earlier, the semantics of IP address delegation start from Figure 9: Convergence times by S-BGP using CRLs to validate IANA. Aiello et al. [1] expressed IP addresses of the Inter- certificates. 50,000 200 45,000 180 46,009 40,000 160 35,000 140 Time (seconds) 120 30,000 100 25,000 80 20,000 15,429 60 15,000 10,518 10,519 40 10,000 20 5,000 0 BGP OA- OA- OA-AS- OA- 0 OA-Simple OA-List OA-AS-List OA-Tree Simple List List Tree Figure 10: Number of verification operations by OA address Figure 12: Convergence time by OA address delegation attesta- delegation attestation constructions. tion constructions. This randomly chosen path determines what address del- tion verification possible. However, as Aiello et al. also egation attestations are involved. mention, in-band delivery of delegation attestation is sus- ceptible to replay attacks, unless we introduce short-lived tokens or make delegation attestations short-lived. Thus, 6.1 Signatures and Verification a trade-off exists between the period of vulnerability and the overhead of administration and computation. Time Figure 10 through Figure 12 show the processing latency. We assume that organizations prepare the delega- Memory We let BGP speakers cache verified attesta- tion attestations offline; the simulation only counts signa- tions and associated prefixes; we then measure the aver- ture verifications and hashing latencies accordingly. The age memory cost and message size. Table 5 shows that OA-List and OA-Tree approaches greatly reduce the num- the OA-List scheme is more costly than other schemes, ber of signature verifications required. Compared with mainly because the list construction produces extremely path authentication schemes, the increase of convergence long delegation attestations. In the approximated address time by all delegation attestation constructions are man- delegation graph, the average number of delegations made ageable. This result, again, implies the verification over- by organizations is about 56.96. Moreover, about 16 or- heads are a minor factor to convergence time compared to ganizations make 80% of the address delegations. Obvi- signing operations. ously, this graph has high connectivity and the delegations The resulting convergence time of OA confirms the are concentrated on very small portion of organizations. conclusion made by Aiello et al. [1]—the efficiencies af- These features are the reason why the AS-List approach forded by OA designs make in-band delegation attesta- can produce long lists of prefixes in address delegation at- testations. According to Figure 10, the AS-Tree approach handles the least number of signatures; however, its mem- 1,600 ory cost and message size are worse than OA-AS-List, 1,400 Basic mainly because the AS-Tree approach involves hash val- Crypto ues, which are much longer than organization identifiers. 1,200 Time (seconds) 1,000 800 6.2 Certificate Revocation 600 The above analysis shows that the OA-AS-List attestation 400 construction is fairly efficient. It is the most efficient one 200 on memory cost and message size, and it does not put 0 significant pressure on BGP processing and convergence. BGP OA- OA- OA-AS- OA- Simple List List Tree In fact, the OA-AS-List construction—the delegation list grouped by different delegatees—is very similar to the de- Figure 11: Total CPU time by OA address delegation attestation sign of address allocation certificates of S-BGP. Thus, we constructions. next consider the case that BGP speakers send S-BGP ad- Attestation Constructions OA-Simple OA-List OA-AS-List OA-Tree Storage for Attests. (KB) 42.80 666.27 13.23 30.22 Message Size (Bytes) 496.97 36293.37 575.35 1029.24 Table 5: Average memory cost and message size by OA address delegation attestation constructions. 210 6.3 Certificate Distribution 200 In addition to processing latency and convergence time, 190 the experiments also measure message size. Carrying cer- tificates in Update messages would require 2KB on aver- seconds 180 age. The maximum message size about 4KB. Given the BGP message MTU, carrying these certificates does not 170 appear to be feasible in practice. On the other hand, if BGP speakers record all certificates locally, our simula- 160 tion shows that certificates consume about 6KB storage on each BGP speakers, on average. The relatively small 150 0 20 40 60 80 100 120 scale of the simulated network prevents us from directly Number of Expired CRLs inferring potential storage issues in the real world. IP ad- dress allocations, AS number assignments, and router as- Figure 13: Convergence times by origin authentication using signments on the full Internet produce much more certifi- CRLs to check certificate status. cates. The CIDR BGP report from AS1221 (Telstra) [4] shows that there are 181,031 active BGP entries in a rout- ing table. To validate ownerships of these prefixes, we dress allocation certificates, instead of delegation attesta- need roughly the same number of address allocation cer- tions in Update messages. In other words, the sender en- tificates. Besides, this report also concludes that there closes the complete certification chain for the verification are about 18,233 unique ASes and 50,000 organizations. of address attestation (AA). We assume that each speaker Considering both PKIs by S-BGP, each BGP speaker sets ICANN and the CA in their local PKI domain as its needs about 190MB in total to store all certificates. trust anchors. Again, bringing this PKI one step closer to reality re- quires considering the costs of checking the validity of the certificates. We consider each approach in turn. 7 Related Work The performance studies in [16, 18] offer detailed discus- sions on deploying S-BGP in the real world. The authors OCSP As before, we first consider OCSP, both in se- collected a variety of data sources to analyze S-BGP’s per- quence and in parallel. Table 6 shows the experiment formance impacts on BGP processing, transmission band- results on processing latency. The most important con- width, and routing table size. These studies concluded clusion we can draw is that, as for path authentication, that the memory requirements of holding route informa- OCSP processing for origin authentication can greatly tion and related cryptographic data are a major obstacle to slow down the BGP convergence. For either part of BGP deployment of S-BGP. Unlike our work, all of the discus- route authentication, using OCSP to validate real-time sions are based on static measurement of BGP. certificate status does not appear to be feasible in practice. The origin authentication study by Aiello et al. [1] de- signed a simulator, OASim, to model the operations of a single BGP speaker. This simulator accepts timed BGP CRLs Again, we carried out experiments assuming dif- Update streams and computes the costs associated with ferent sets of CRLs expire at the routers, and examined the validation and storage of the related origin authentica- performance. Figure 13 shows the results. The curve tion proofs. The simulation results show that in-band dis- is similar to the convergence time by path authentication tribution of origin authentication proofs is possible. Our with CRL fetching. The convergence time is relatively un- simulation is more powerful than OASim in that we model affected if each of the BGP speakers needs to fetch fewer and simulate a network and study the convergence time. than eight CRLs during rebooting. Our previous study [27] used a packet-level detailed Protocol # Ann. # Vrf. # Attest. # OCSP Rqst. Basic CPU (s) Crypto CPU (s) Convergence (s) BGP 19571.8 – – – 1310.6 – 153.7 OA-AS-List 20131.2 15429.1 10364.1 – 1349.7 480.4 155.1 Sequential OCSP 22800.5 73586.7 5071.0 68515.65 1522.1 53665.7 2420.9 Parallel OCSP 22408.6 72635.2 5071.2 67564.00 1494.8 19060.2 938.7 Table 6: Convergence impact of OCSP on in-band address attestation. simulation model of BGP to understand the processing 8 Conclusions overhead by S-BGP. We discovered that, due to public key cryptography, S-BGP is expensive on operational latency Implementation details of securing BGP have signifi- and thus greatly increases convergence time. We further cant impact on BGP’s behavior, and on the capacity of proposed a more efficient scheme (signature amortization, routers to actually use the algorithms. BGP’s detailed S-A) for BGP path authentication. Our simulation experi- time and memory consumption is too complex to analyze ments conclude that the new approach has minimal impact purely with mathematics, and so we turn to large-scale on BGP convergence. discrete-event simulation to examine the impacts of cryp- There are also other studies on more efficient mecha- tographic operations and standard PKI certificate valida- nisms for securing BGP. One challenge in the adoption tion schemes on recent proposals to secure BGP. of any inter-domain routing security solution is its inte- We compare several major security proposals with S- gration with existing infrastructure. In the Inter-domain BGP. Our simulation results have shown that it is pos- Routing Validation (IRV) project [8], participating ASes sible to apply more efficient cryptographic operations to host servers called IRVs. Each IRV maintains a consistent improve the performance in terms of convergence time, corpus of routing data received and advertised. Remote message size, or storage costs. Tradeoffs exist. Different entities (e.g., routers, other IRVs, application) validate lo- proposals have their own strengthens and weakness. In cally received data by querying source AS IRVs using an particular, Signature Amortization achieves fast conver- out-of-band (and potentially secure) protocol. This ap- gence at the cost of longer message size and more mem- proach has the advantage that the query responses can be ory. Sequential Aggregation Signatures can decrease the tailored to the requester for optimization or access control. message size, but slowing down the BGP convergence sig- A recent effort that attacks the scalability issue of S- nificantly. The Origin Authentication scheme can achieve BGP is psBGP [40]. The major goal is to increase prac- instant origin proofs with in-band distribution of attesta- ticability of security solutions on BGP. The psBGP pro- tions, at the cost of exposing vulnerabilities to attackers. tocol contains four main components—authentication of We also analyzed the impacts of standard certificate AS numbers, authentication of IP prefix ownership, au- revocation/validation mechanisms. The OCSP approach thentication of BGP speakers, and integrity of AS path. greatly slows down convergence. On the other hand, if Essentially, this proposal combines aspects of S-BGP and BGP speakers rely on CRLs for certificate validation, the soBGP. extra overheads by CRL handling operations are insignif- Besides public key cryptography, there are efforts on icant to affect convergence. Of course, such choices trade securing BGP using symmetric key algorithms [9, 13, 42]. performance with security. These proposals are more efficient on the operational la- Besides BGP routing system, a variety of other large- tency, but require more storage, loose time synchroniza- scale distributed systems assume an underlying PKI—but tion, and complex key-pair pre-distribution. neglect to consider its performance impact. Understand- Subramanian et al. [36] proposed the Listen and Whis- ing the impact of the underlying PKI systems is a chal- per protocols to address the BGP security problem. The lenging task. In the future, we plan to analyze broader Listen protocol helps data forwarding by detecting “in- issues of PKI design and deployment that satisfy the se- complete” TCP connection; the Whisper protocol uncov- curity and performance requirements by these large-scale ers invalid route announcements by detecting inconsis- distributed systems and applications. tency among multiple update messages originating from In ongoing work, we are also exploring new path au- a common AS. The Listen and Whisper approach dis- thentication protocols that further improve performance. penses with the requirement of PKI or a trusted central- ized database, and aims for “significantly improved secu- rity” rather than “perfect security.” Acknowledgments [12] R. Housley, W. Polk, W. Ford, and D. Solo. Internet X.509 Public Key Infrastructure Certificate and CRL Pro- The authors are grateful to Patrick McDaniel, Kevin But- file. RFC3280, http://www.ietf.org/rfc3280.txt, ler, William Aiello, Steve Kent, Scot Rea, B. J. Premore, April 2002. and Hongsuda Tangmunarunkit for their valuable sugges- [13] Yih-Chun Hu, Adrian Perrig, and Marvin Sirbu. SPV: Se- tions. This research has been supported in part by Sun, cure Path Vector Routing for Securing BGP. In Proceed- Cisco, the Mellon Foundation, NSF (CCR-0209144, EIA- ings of SIGCOMM 2004, pages 179–192. ACM Press, Au- 9802068), AT&T/Internet2 and the Office for Domestic gust 2004. Preparedness, Department of Homeland Security (2000- [14] IANA: Internet Assigned Numbers Authority. http:// DT-CX-K001). This paper does not necessarily reflect the www.iana.org. views of the sponsors. [15] Internet corporation for assigned names and numbers. http://www.icann.org. References [16] Stephen Kent, Charles Lynn, Joanne Mikkelson, and Karen Seo. Secure Border Gateway Protocol (S-BGP) – Real [1] William Aiello, John Ioannidis, and Patrick McDaniel. World Performance and Deployment Issues. In The 7th Origin Authentication in Interdomain Routing. In Pro- Annual Network and Distributed System Security Sympo- ceedings of the 10th ACM Conference on Computer and sium (NDSS’00), San Diego, California, February 2000. Communications Security, pages 165–178. ACM Press, [17] Stephen Kent, Charles Lynn, and Karen Seo. Secure Bor- October 2003. der Gateway Protocol. IEEE Journal of Selected Areas in [2] Dan Boneh, Craig Gentry, Ben Lynn, and Hovav Shacham. Communications, 18(4):582–592, April 2000. A Survey of Two Signature Aggregation Techniques. RSA [18] Steve Kent. Securing the Border Gateway Protocol: A Sta- CryptoBytes, 6(2):1–10, 2003. tus Update. In Seventh IFIP TC-6 TC-11 Conference on [3] Dan Boneh, Craig Gentry, Ben Lynn, and Hovav Shacham. Communications and Multimedia Security, October 2003. Aggregate and Verifiably Encrypted Signatures from Bilin- ear Maps. In Proceedings of Eurocrypt 2003, number 2656 [19] Craig Labovitz, Abha Ahuja, Abhijit Bose, and Farnam in LNCS, pages 416–432. Springer-Verlag, 2003. Jahanian. Delayed Internet Routing Convergence. In Proceedings of SIGCOMM 2000, pages 175–187, August [4] CIDR BGP Reports from AS1221 (Telstra), October 2004. 2000. http://www.cidr-report.org/as1221/. [20] Craig Labovitz, Abha Ahuja, and Farnam Jahanian. Exper- [5] James Cowie, David Nicol, and Andy Ogielski. Model- imental Study of Internet Stability and Wide-Area Back- ing the Global Internet. IEEE Computing in Science and bone Failures. In Proceedings of the International Sympo- Engineering, 1(1):42–50, Jan.–Feb. 1999. sium on Fault-Tolerant Computing, June 1999. [6] Michalis Faloutsos, Petrof Faloutsos, and Christos Falout- [21] Craig Labovitz, Abha Ahuja, Roger Wattenhofer, and sos. On Power-Law Relationships of the Internet Topol- Srinivasan Venkatachary. The Impact of Internet Policy ogy. In Proceedings of ACM SIGCOMM’99, pages 251– and Topology on Delayed Routing Convergence. In Pro- 262. ACM Press, 1999. ceedings of INFOCOM 2001, pages 537–546, April 2001. [7] Lixin Gao. On Inferring Autonomous System Relation- ships in the Internet. IEEE/ACM Transactions on Network- [22] Anna Lysyanskaya, Silvio Micali, Leonid Reyzin, and Ho- ing (TON), 9(6):733–745, December 2001. vav Shacham. Sequential Aggregate Signatures from Trap- door Permutations. In Eurocrypt 2004, volume 3027 of [8] Goeffrey Goodell, William Aiello, Timothy Griffin, John LNCS, pages 74–90. Springer-Verlag, 2004. Ioannidis, Patrick McDaniel, and Aviel Rubin. Working around BGP: An Incremental Approach to Improving Se- [23] Zhuoqing Morley Mao, Ramesh Govindan, George Vargh- curity and Accuracy in Interdomain Routing. In The 10th ese, and Randy H. Katz. Route Flap Damping Exacer- Annual Network and Distributed System Security Sympo- bates Internet Routing Convergence. In Proceedings of sium, San Diego, California, February 2003. SIGCOMM 2002, August 2002. [9] Michael Goodrich. Efficient and Secure Network Routing [24] R. Merkle. Protocols for Public Key Cryptosystems. In Algorithms. provisional patent filing, http://www.cs. Proc 1980 Symposium on Security and Privacy, IEEE jhu.edu/∼goodrich/cgc/pubs/rout-ing.pdf, Jan- Computer Society, pages 122–133, April 1980. uary 2001. [25] R. Merkle. A Certified Digital Signature. In G. Brassard, [10] Ramesh Govindan and Anoop Reddy. An Analysis of In- editor, Advances in Cryptology – CRYPTO ’89, volume ternet Inter-Domain Topology and Route Stability. In Pro- 435 of Lecture Notes in Computer Science, pages 218–238. ceedings of INFOCOM 1997, pages 850–857, April 1997. Springer-Verlag, 1990. [11] Timothy G. Griffin and Gordon Wilfong. An Analysis [26] S. Murphy. BGP Security Vulnerabilities Analysis. of BGP Convergence Properties. In Proceedings of SIG- Internet-Draft, draft-murphy-bgp-vuln-00.txt, NAI Labs, COMM 1999, pages 277–288, August 1999. February 2002. [27] David M. Nicol, Sean W. Smith, and Meiyuan Zhao. Eval- [42] K. Zhang. Efficient Protocols for Signing Routing Mes- uation of Efficient Security for BGP Route Announce- sages. In The 5th Annual Network and Distributed Sys- ments using Parallel Simulation. Simulation Practice and tems Security Symposium (NDSS’98), San Diego, Califor- Theory Journal, special issue on Modeling and Simulation nia, March 1998. of Distributed Systems and Networks, 12(3–4):187–216, July 2004. [28] Andy T. Ogielski and James H. Cowie. SSFNet: Scal- able Simulation Framework - Network Models. http: //www.ssfnet.org. See http://www.ssfnet.org/ publications.html for links to related publications. [29] OpenSSL: The Open Source toolkit for SSL/TLS. http: //www.openssl.org. [30] Dan Pei, Xiaoliang Zhao, Lan Wang, Dan Massey, Allison Mankin, S. Felix Wu, and Lixia Zhang. Improving BGP Convergence through Consistency Assertions. In Proceed- ings of INFOCOM 2002, June 2002. [31] Brian Premore. An Analysis of Convergence Properties of the Border Gateway Protocol Using Discrete Event Simu- lation. PhD thesis, Dartmouth College, June 2003. [32] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP- 4). RFC1771, http://www.ietf.org/rfc1771.txt, March 1995. [33] The Route Views Project. http://www.antc.uoregon. edu/route-views/. [34] Aman Shaikh, Anujan Varma, Lampros Kalampoukas, and Rohit Dube. Routing Stability in Congested Networks: Ex- perimentation and Analysis. In Proceedings of SIGCOMM 2000, pages 163–174, August 2000. [35] B. Smith and J.J. Garcia-Luna-Aceves. Efficient Secu- rity Mechanisms for the Border Gateway Routing Proto- col. Computer Communications (Elsevier), 21(3):203– 210, 1998. [36] Lakshminarayanan Subramanian, Volker Roth, Ion Stoica, Scott Shenker, and Randy H. Katz. Listen and Whisper: Security Mechanisms for BGP. In Proceedings of First Symposium on Networked Systems Design and Implemen- tation (NSDI 2004), March 2004. [37] MitreTek Systems. Certificate Arbitrator Module. http: //cam.mitretek.org/cam/. [38] Hongsuda Tangmunarunkit, Ramesh Govindan, Scott Shenker, and Deborah Estrin. The Impact of Routing Pol- icy on Internet Paths. In Proceedings of INFOCOM 2001, pages 736–742, April 2001. [39] Iljitsch van Beijnum. BGP: Building Reliable Networks with the Border Gateway Protocol. O’Reilly, 2002. [40] Tao Wan, Evangelos Kranakis, and P.C. van Oorschot. Pretty Secure BGP (psBGP). In The 12th Annual Network and Distributed System Security Symposium (NDSS’05), San Diego, California, February 2005. [41] Russ White. Architecture and Deployment Considera- tions for Secure Origin BGP (soBGP). IETF Internet Draft http://www.ietf.org/internet-drafts/ draft-white-sobgparchitecture-00.txt, May 2004. Evaluating the Performance Impact of PKI on BGP Security Meiyuan Zhao, Sean Smith Dartmouth College David Nicol University of Illinois at Urbana-Champaign Outline † Overview „ BGP „ S-BGP’s PKIs and attestations † Improved schemes „ OA, S-A, and SAS † Performance evaluation „ Simulation methodology „ Experiment results † Related work † Conclusions and future work Border Gateway Protocol (BGP) † Inter-domain routing protocol † Mainly between autonomous systems (ASes) † Updates are in form of route announcements (AS_PATH, prefix) A sequence of AS numbers A range of IP addresses (prefix) e.g., “500 300 100” e.g., 129.170.0.0/16 p },p 4 1 , 2, {1}, p {2, 1}, p {3 1 2 3 5 {3, 2, 1}, p Secure BGP (S-BGP) AS path Prefix Route Attestations (RAs) Address Attestations (AAs) † IP address owners create AAs † X.509 Certificates for IP address allocation „ (prefix1, …, prefixk, orgy) address assignment † Routers create RAs † X.509 Certificates for AS# and Routers „ (AS, AS#, PK) binding „ (RtrID, AS#, PK) binding S-BGP PKIs † Match existing infrastructures AS number assignment & IP Address Allocation Binding a Router to an AS ICANN ICANN APNIC ARIN RIPE LACNIC APNIC ARIN RIPE … AT&T AS numbers IP address blocks … Organizations … ISP / DSP / Subscribers AS numbers RtrID … (ASk, ASNs) (RtrID, ASN) Subscribers Certificate Distribution † Scale „ 197,709 active prefixes „ 19,357 unique ASes „ >50,000 organizations † BGP Update message MTU: 4KB † S-BGP X.509 Certificates: 600 bytes † Store certificates/CRLs locally „ >200MB S-BGP Address Attestations (AAs) † Authorize ASes to originate routes † CAs prepare and distribute AAs † Long-lived, need revocation ICANN APNIC ARIN RIPE … AT&T IP address blocks … ISP / DSP / Subscribers … Subscribers {prefix list, ASN} orgx Origin Authentication (OA) † Short-lived IANA attestations APNIC ARIN RIPE … AT&T † Possible in-band … IP address blocks transmission for ISP / DSP / Subscribers … address delegation paths AS1 AS2 ASk † Variants „ OA-Simple {(p, org)}K „ OA-List {(p1, org1), (p2, org2), …, (pi, orgi)}K „ OA-AS-List {(p1, p2, …, pk, org)}K „ OA-Tree Merkle hash tree, leaves: (pi, orgi) Aiello, Ioannidis, and McDaniel. “Origin Authentication in Interdomain Routing”. CCS03 Evaluation Methodology † AS-level network simulation—110 ASes † BGP router under stress—router reboot † PKI model „ ASes, Routers, Organizations, CAs, Directories, and OCSP responders „ Routers trust the roots, and OCSP responders; may trust other CAs as well „ Check certificate revocation status † OCSP—sequential or parallel requests † CRLs (fetch fresh copies) † Reduced OA approximate delegation graph † Metrics „ Speed—BGP convergence time „ Memory „ Message Size OA Signature Performance—Convergence † Slight slow down convergence time 240 181.3 200 166 seconds 153.7 155.1 156.2 160 120 80 40 0 BGP OA- OA-List OA-AS- OA-Tree Simple List OA Signature Performance—Storage † Different costs on memory and message size † OA-AS-List is most efficient † Possible in-band transmission Attestation Memory for Message Size Constructions Attestations (Bytes) (KB) OA-Simple 42.80 496.97 OA-List 666.27 36293.37 OA-AS-List 13.23 575.35 OA-Tree 30.22 1029.24 OA Performance—OCSP requests † ≈ 68,000 OCSP requests Convergence Time of OCSP Requests 3000 2420.9 2500 seconds 2000 1500 938.7 1000 153.7 155.1 500 0 BGP OA-AS-List Sequential Parallel OCSP OCSP OA Performance—CRLs fetching Convergence Time of CRL Fetching 210 200 190 seconds 180 170 160 150 0 20 40 60 80 100 120 Number of Expired CRLs Secure BGP (S-BGP) AS path Prefix Route Attestations (RAs) Address Attestations (AAs) † IP address owners create AAs † X.509 Certificates for IP address allocation „ (prefix1, …, prefixk, orgy) address assignment † Routers create RAs † X.509 Certificates for AS# and Routers „ (AS, AS#, PK) binding „ (RtrID, AS#, PK) binding S-BGP Route Attestations (RAs) † Router signs (new AS number, prefix, next_hop) † Sends all previous signatures † Verify aspath {1, 2, 3} „ Needs 3 signatures † Sign aspath {1, 2, 3} „ Creates n signatures 1, p, 2 2, p, 3 3, p, 4 1 2 3 4 {3, 2, 1}, p † Signature Algorithm—DSA Signature Amortization (S-A) † Fast signature verification—RSA † Few signature signing—aggregate messages „ Bit vectors „ Merkle hash trees † Auxiliary values for each signature m1 B1 m2 B2 mk Bk Router output buffers Grouped messages Aggregated hash “Evaluation of efficient security for BGP route announcements using parallel simulation” Nicol, Smith, and Zhao. Simulation Modelling Practice and Theory Journal, Vol. 12, Issue 3—4, 2004 Sequential Aggregate Signature † k signers {s1, s2, …, sk} k messages {m1, m2, …, mk} one aggregate signature σ 1, p, 2 2, p, 3 σ 3, p, 4 † One aggregate signature for entire AS path Lysyanskava et al. “Sequential Aggregate Signatures from Trapdoor Permutations”. Eurocrypt2004 PA Signature Performance—Convergence † S-A converges fast — aggregates 60 messages 700 621.1 600 507.5 500 seconds 400 300 224.4 153.7 168.5 200 100 0 BGP S-BGP S-BGP S-A SAS (c p) PA Signature Performance—Message † SAS — shortest messages † S-A — longest messages 1200 1107.1 1000 800 bytes 600 318.6 400 184.3 200 36.1 0 BGP S-BGP S-A SAS PA Signature Performance—Memory † S-A — expensive on memory 350 314.3 300 kilobytes 250 200 122 150 112.2 100 50 9 0 BGP S-BGP S-A SAS PA PKI Performance—OCSP Requests † ≈ 88,000 OCSP requests Convergence Time of OCSP Requests 3000 2720.4 2500 2000 seconds 1500 1000 224.3 334.3 500 153.7 0 BGP S-BGP Sequential Parallel OCSP OCSP PA PKI Performance—CRLs Fetching Convergence Time of CRL fecthing 290 convergence time (seconds) 280 270 260 250 240 230 220 0 20 40 60 80 100 120 Number of Expired CRLs Related Work † S-BGP [Kent:NDSS00] † OASim [Aiello:CCS03] † psBGP [Wan:NDSS05] † Listen and Whisper [Subramanian:NSDI04] † Symmetric cryptography „ Potentially more efficient „ Key distribution [Goodrich00] „ Time synchronization [Hu:SIGCOMM04] Conclusions † PKI proposed for a REAL problem † Large-scale network simulation † Performance trade-offs „ PKIs † S-BGP cert out-of-band transmission vs. OA in-band transmission † OCSP timely notification vs. CRLs fast status checking „ Signature processing † S-A fast speed vs. SAS short messages Next Steps † More efficient public key cryptography „ Combine S-A and SAS † Certificate-using decisions „ Revoke routes, if a certificate is revoked? † Comprehensive PKI simulation model „ Issuing/revoking activity „ Certification path discovery/validation Thank you! † Sun Microsystems † Mellon Foundation † Cisco Systems † Intel Corporation † NSF † DoJ/DHS † Email zhaom@cs.dartmouth.edu † Homepage http://www.cs.dartmouth.edu/~zhaom Benchmarks SHA-1 hash MD5 hash Attestations Certificates Identifier Length 20 bytes 16 bytes 110 bytes 600 bytes 4 bytes RSA DSA DSA(p) SAS Verify Time (ms) 2.5 31.0 31.0 2.5 Sign Time (ms) 50.0 25.5 0.015 50.0 Signature length (bytes) 128 40 40 128 OCSP request CRL fetching Operation latency (second) 0.5—1.0 0.5—1.0 a valid identity certificate. Component certificates Observations from the Deployment are issued to web servers and other devices. Code of a Large Scale PKI signing certificates are issued to specific entities Rebecca Nielsen within the DoD that approve mobile code. Booz Allen Hamilton Other DoD PKI core components include the internal directory servers and the Key Escrow Database 1 Background (KED). All private keys associated with encryption certificates are escrowed prior to the issuance of the The United States Department of Defense (DoD) has certificate. been investigating the use of public key technology to help meet its information assurance goals since The DoD PKI supports two interfaces for certificate 1997. The DoD implemented a pilot Public Key issuance, hardware and software. Hardware Infrastructure (PKI) in 1998, and began a mass certificates are issued on the CACs to all DoD rollout of the current DoD PKI in 2000. Since then, personnel. The CAC is a Java smart card that has the DoD has successfully issued digital certificates on been validated against Federal Information Common Access Cards (CAC) to over 85% of its 3.5 Processing Standard (FIPS) 401 Level 2 million user population. While the deployment of the requirements. The Java card was selected both to DoD PKI has not always been smooth, the issuance allow for the inclusion of additional functionality of digital certificates has been one of the first truly beyond PKI on the card and to enable multiple enterprise-wide standard technology implementations vendors to provide card stock to the DoD. Identity within the DoD. proofing and certificate issuance on the CAC take place using the DoD’s existing personnel This paper provides insight into some of the identification card issuance system. Since the CAs technology and organizational lessons learned in do not have a direct method for interfacing with the deploying the world’s largest PKI from the CAC, issuance portals are used to facilitate key perspective of a DoD contractor. generation, certificate request generation, and insertion of issued certificates. 2 Managing the “I” in PKI Software certificates can be issued to people and web servers. Although the CAC is the primary issuance 2.1 The DoD PKI Architecture process for personnel, software certificates are used The DoD PKI consists of a to support some legacy single Root Certification applications that do not yet Authority (CA) and multiple support hardware tokens, subordinate CAs. The Root and in some environments CA only issues subordinate where CAC issuance is CA certificates. difficult. Software Subordinate CAs issue five certificates are requested via types of certificates: a Hyper Text Transfer identity, signature, Protocol, Secure (HTTPS) encryption, component, and interface and verified by code signing. Identity and Registration Authorities signature certificates can be (RA) and Local Registration used to authenticate to Authorities (LRA). applications or digitally sign For publication of PKI forms or email messages. information, the DoD PKI Because many DoD email interfaces with the Global addresses change when Directory Service (GDS). individuals move from one GDS is an internal location to another, the DoD enterprise directory that issues the primary identity supports both HTTPS and certificate with no email address. The signature and Lightweight Directory Access Protocol (LDAP) encryption certificates contain email addresses to interfaces. Subordinate CA certificates, Certificate support Secure/Multipurpose Internet Mail Revocation Lists (CRL), and encryption certificates Extensions (S/MIME) version 2 and 3. New email are published to the GDS from the DoD PKI. certificates can be issued based on the presentation of Subordinate CA certificates and CRLs are also published to an external X.500 directory for access Although the GDS is the primary interface for outside of the DoD. applications to retrieve CRLs and for end users to search for encryption certificates, direct searches of Certificate revocation is performed by RAs using an the CA internal databases are still required, primarily HTTPS interface. Key recovery is performed by key for certificate revocation. When requesting recovery agents who access the KED using an certificate revocation, most users and supervisors do HTTPS interface. not know the CA and serial number for the certificate that needs to be revoked. As a result, the RA must 2.2 Certification Authority (CA) Scalability search multiple CAs to locate the correct certificate prior to authorizing its revocation. Take into account all of the required tasks when developing architecture requirements. 2.3 Hardware and Software Maintenance When designing the infrastructure, the DoD performed load testing to determine how many PKI cycle times are significantly different certificates a given CA could issue. However, this then hardware and software cycle times. initial load testing did not account for the many other functions that CAs must be able to perform at the 2.3.1 CA Hardware and Software same time as certificate issuance, including the The DoD PKI was designed for the long term. The following: DoD Root CA has a validity period of thirty-six • validating credentials of trusted personnel, years. Each subordinate CA has a validity period of six years. Subordinate CAs issue certificates for the • publishing certificates, first three years of their validity period and are then • generating CRLs, “retired” so that they only issue CRLs for the • publishing CRLs, remaining three years. CAs are only taken • revoking certificates, completely out of service once all certificates issued by the CA have expired. CACs issued to • responding to requests to search for specific Government personnel are valid for three years, certificates. while those issued to contractors are valid for up to The DoD PKI has over 2,000 approved RAs. one year. Because of personnel turnover, the list of approved In contrast, hardware life cycles are one to three RAs changes frequently. To ensure that certificates years, and software product cycles can be eighteen can still be issued if one or more CAs are months or less. As a result, neither the software nor unavailable, the DoD PKI is configured so that all the hardware in use for the DoD Root CA are still RAs are authorized on all CAs. The interface supported by their respective vendors. Older provided by the vendor to manage trusted personnel subordinate CAs are also operating on non-supported did not support the large number of RAs or the versions of hardware and software, increasing both requirement for frequent updates. To minimize the the requirement for and the cost of maintenance. impact to CAs, the DoD has developed custom scripts that allow changes in RA personnel to be 2.3.2 Key Length quickly uploaded to all CAs. In addition to product life cycles, the basic The process of generating CRLs requires significant technology behind PKI is also changing. When the CA processing time, both in determining which Root CA was established, 512-bit keys were still in certificates have been revoked, and, as the CA ages, use, and 1024-bit keys were the longest supported by determining which revoked certificates have expired vendors. Today, 1024-bit keys are standard, and the and should not be placed on subsequent CRLs. For Federal Government has published guidelines that all CAs that issue a large number of certificates, the certificates that will expire later than 2008 should be requirement to check each revoked certificate for its issued with 2048-bit keys. expiration date can cause the total time to generate a CRL to be greater than the next update period of the As a result, the DoD PKI is currently working on a CRL. While CRL generation requires less processing solution to upgrade the Root CA. There are two time if expiration date checks are not performed, options for upgrading, migrating the current Root CA continuing to include expired certificates on CRLs to newer hardware and software versions, or increases the overall CRL size. establishing a new Root CA and issuing a rollover certificate from the current Root CA to the new Root CA. Migrating the existing Root CA is simpler for the short term, but does not solve the problem of the the 32k chip currently supported. This new chip will 1024-bit Root CA signing key length. support additional capabilities beyond PKI. The additional space may also support better security Establishing a new Root CA with a 2048-bit signing protections, which would enable users to perform key will require pushing down the new key to all more card maintenance, such as certificate update, applications relying on certificates from the DoD from their own workstations instead of having to PKI. In addition, a new Root CA will require return to an issuance station. However, all DoD users maintaining two infrastructures for three to six years, will not be able to take advantage of these new depending on whether all current subordinate CAs capabilities until all cards have been replaced through are retired when the new Root CA is established. normal expiration. 2.3.3 Certificate Profile 2.4 Personnel Another issue with the long term nature of the PKI is that changes to certificate profiles require over three Integrating PKI rollout with existing years to implement. For example, the DoD PKI processes is a requirement for success. initially did not support the extensions required to use digital certificates to authenticate to Microsoft The initial DoD PKI rollout was planned as a Windows-based networks. Windows requires the software-based implementation. The DoD would following extensions in certificates1: centrally manage the PKI core components, and each DoD service or agency would provide personnel to • CRL Distribution Point must be present, act as RAs and LRAs who would register individuals. • Key Usage must be set to Digital Signature, When early adopter applications tried to get their • Extended Key Usage (EKU) must contain the users registered to get certificates, however, they Smart Card Logon Object Identifier (note that if found that RAs and LRAs were not available. Local the EKU extension is populated, it must also commands resisted the requirement for additional contain the identifiers for all other uses for the personnel, and the travel costs for sending RAs and certificates, such as Client Authentication), LRAs to training. • Subject Alternative Name must contain a User At the same time the PKI was performing initial Principal Name (UPN) of the format rollout, the personnel office was developing a new user@name.com. identification (ID) card to be rolled out to all DoD Once the requirements were determined and the military and civilian employees. In November 1999, changes implemented at the subordinate CAs, all new the DoD made a decision to combine the two CACs contained a signature certificate with the programs and use the new ID card as a hardware additional information. However, there are still token for digital certificates. As a result of this some subscribers within the DoD that do not have the decision, the PKI and personnel offices worked required extensions on their CACs. together to design a process that used existing ID card issuance stations to verify identity and issue Another example is the Authority Information Access certificates in conjunction with ID cards. extension. Research by the Federal Bridge Path Discovery and Validation Working Group has This new process did increase the personnel indicated that path discovery is facilitated when requirements for ID card issuance stations. Prior to certificates contain the Authority Information Access the CAC, DoD ID cards were only issued to military (AIA) extension 2. The DoD PKI does not currently personnel, but CACs are issued to military personnel, include the AIA extension. If the DoD makes a civilian employees, and on-site contractors. Also, the decision to modify its certificate profiles to include time to issue CACs is longer then the time to issue the AIA extension, the change will take three years to the old ID cards. However, combining certificate be reflected in all DoD PKI issued certificates. issuance with ID card issuance allowed the PKI to take advantage of the existing ID card infrastructure 2.3.4 Smart Card Technology and minimized the personnel requirements for services and agencies. Also, the requirement for In addition to CA and certificate profile updates, the personnel to get a new ID card facilitated the DoD must manage user smart card migration issues. issuance of certificates. Since most CACs are valid for three years, CAC middleware must concurrently support three years of smart card technology. The DoD is investigating upgrading new card stock to a 64k chip, instead of 3 Technology Challenges The DoD PKI has examined two alternate CRL approaches, partitioned CRLs and delta CRLs. A CA Building the capability to support the DoD enterprise creating partitioned CRLs divides certificates into is not sufficient for the success of the DoD PKI. blocks of a preset size based on information Since PKI is an infrastructure technology, it does not contained in the certificate such as the certificate solve any operational requirements unless public key serial number. Instead of issuing one CRL, the CA technology is integrated into applications. This issues multiple CRLs, one for each preset block of section explores the two most significant challenges certificates. When an application attempts to validate that the DoD PKI has experienced in gaining a certificate, it checks to see if a current CRL for the acceptance from the functional community for the block the certificate is contained in is locally cached, use of PKI. and downloads the CRL partition if it is not. While partitioned CRLs allow applications to only retrieve 3.1 Certificate Status Checking limited CRL information, the DoD has not developed a solution involving partitioned CRLs, partially Checking certificate revocation status is the because of the lack of support from either CA or most difficult technical challenge of PKI. application vendors. CRLs are theoretically elegant. They provide a A CA supporting delta CRLs issues a full CRL once mechanism for a CA to state that it no longer asserts or periodically, and then only issues delta CRLs that the binding between the identity in the certificate and contain certificates that have been revoked since the the associated key pair for a set of certificates that it last delta CRL was issued. As a result, delta CRLs issued. CRLs provide only a minimum set of data, are significantly smaller than full CRLs. However, the certificate serial number, the date of revocation, applications must have a mechanism of ensuring that and optionally a reason for revocation. Because they they have downloaded all delta CRLs, because no are digitally signed, the transmission mechanism does single CRL can be considered an authoritative source not itself have to be trusted in order to accept the for information on the revocation status of any given information contained in the CRL. certificate. Although the DoD PKI does not support In practice, however, relying on CRLs has not delta CRLs, one agency within the DoD has worked well. Products that are enabled to use digital successfully piloted a delta CRL approach for certificates only provide minimal support for CRLs. transmitting revocation information in a severely In some cases, no provision is provided to automate bandwidth constrained environment. the downloading of CRLs. Vendors who do provide In general, CRLs have been an effective method of an automated update capability may not allow setting transmitting revocation information across enterprise when the attempt to retrieve a new CRL occurs, networks with high bandwidth availability, but are which can result in multiple applications attempting too cumbersome to use to get this information down to access the CRL repository at the same time. At to individual applications. least one vendor treats the next update field of a CRL as an expiration date, and will not validate any As a result of the continued issues with performing certificate issued by a CA for which a current CRL is certificate validation using CRLs, the DoD PKI is not available. Finally, the information contained in a deploying an infrastructure to support revocation CRL is only as current as the time the CRL was status checking using the On-line Certificate Status published, which results in significant latency issues. Protocol (OCSP). To meet the requirements for decentralization, availability, and scalability, this The scale of the DoD PKI results in an additional infrastructure will not interface directly with the DoD problem, the overall size of CRLs. The combined PKI CAs. Instead, it will provide a capability to size of the CRLs from all of the DoD PKI CAs is download CRLs and provide real-time OCSP approaching 40 megabytes. It is not feasible for responses from multiple locations across the DoD every application on DoD networks to download this network. Instead of downloading CRLs, applications amount of data every day without having a that support OCSP will able to get real-time significant impact on available bandwidth. responses for specific certificates from this global Although CRLs are an efficient way of publishing robust certificate validation system. Although the revocation information for the entire PKI, no single use of CRLs as the authoritative source for application has all subscribers as users, so each revocation information does not address the latency application only needs a subset of the information. issues of CRLs, this hybrid approach of CRLs and However, the enterprise PKI does not know in OCSP will take advantage of the efficiency of CRLs advance which subset is needed by each application. and provide an interface for applications that is easier 4.1 The Users to implement and maintain. Provide users with new capabilities that help 3.2 Key Recovery them to get their jobs done, not just PKI certificates. The person most likely to need key recovery capability is the subscriber. Most users will embrace new technology if they see a clear benefit to its use. However, PKI was initially The DoD PKI key escrow and recovery solution was marketed as a technology, not as a mechanism for designed when the DoD PKI was primarily issuing getting the job done. For example, “PKI 101” software certificates. The solution was designed to training often starts by stating the concepts of public support situations when a private key needed to be key technology, then introduces the user to “Alice” recovered by a manager or law enforcement agent to and “Bob” who are exchanging signed and encrypted access encrypted data, and occasionally by email messages. By this time, attendees have subscribers who had lost their private keys. As a decided that PKI is very complicated and since they result, the process was manual and personnel can send email without PKI (and have been doing it intensive, requiring first that requestors verify their for years without problems), they leave the training own identities and provide justification for the having decided that PKI is too difficult. request, and then that two key recovery agents The DoD PKI was originally targeted as a pilot that together retrieve the escrowed keys out of storage. would provide better assurance for a new electronic The transition to the CAC as the token for key travel system. Through the use of digital signatures, generation and storage created a significant change in travel claims could be processed significantly faster, the key recovery requirement. Since the private key resulting in shorter times for employee associated with each subscriber’s encryption reimbursements. Once deployed, the PKI could then certificate is stored only on the CAC, subscribers lose be used with other systems. However, delays in the access to their own private keys at CAC expiration rollout of the travel system and the decision to because the old CAC is surrendered at the time of implement a smart card-based PKI meant that many new CAC issuance. In order to access files users were issued a CAC months prior to receiving a previously encrypted, all subscribers must recover smart card reader and without any application their old private keys. requiring use of their new certificates. As a result, most users’ experience with PKI consisted of waiting The manual process which was designed to prevent in line to get a CAC and then using the CAC the abuse of key recovery is too costly to support for a same way they had used the ID card they had prior to large number of individuals requesting their own the CAC. These users did not see any real benefit to escrowed private keys. Since individuals are the new technology. assumed to be authorized to have access to their own keys, a more automated process is being developed Although smart card readers are being deployed and that will allow subscribers to use their identity applications are beginning to incorporate support for certificate to authenticate to the key escrow system public key technology, the DoD PKI continues to and request retrieval of their own private keys. struggle to attain widespread user acceptance. 4.2 The Managers 4 Organizational Challenges Although the implementation of the DoD PKI has Application owners need policy, budget experienced technical challenges, overcoming guidance, and a business justification for organizational obstacles has sometimes proved a adopting public key technology. harder task. Some of these obstacles are independent of PKI, such as issues relating to coordinating Within the DoD, funding for PKI core components common processes across the worldwide enterprise, and card stock is centrally managed. However, developing working relationships between disparate individual applications, including email, networks, commands within the enterprise, and determining and web servers, are very decentralized. Therefore, which organizations within the enterprise should rolling out the PKI required a few decisions by policy have primary responsibility for each element of the makers, but integrating public key technology into overall architecture. This section highlights some of applications requires many decisions by many the organizational challenges specific to PKI application owners. These managers must consider implementation for users, managers, and developers. multiple demands when determining how to allocate capabilities, replacing components with similar limited resources: components from different vendors that support required capabilities, and building interfaces between Getting support from application managers requires enabled components and those that do not support providing managers with the information they need to public key technology. make decisions including the following: Unfortunately, there are relatively few individuals • Ensure that published policy is consistent with the who understand both PKI and application organization’s goals for integrating public key architectures. Available PKI training consists technology. Policy enables early adopters of new primarily of lessons on how to stand up the technology to justify their investments. infrastructure; it does not focus on how to integrate • Provide direction for requesting funding for public PKI into existing applications. Vendors provide key enabling as a part of the standard budget cycle. some guidance, but this information is usually limited Getting out of cycle funding to meet security to the vendor’s own products. driven requirements is difficult and almost always means that other planned functionality must be For example, a web server vendor will provide sacrificed to meet PKI requirements. instructions on how to request and install a server certificate and how to turn on client certificate-based • Use specific examples when presenting security authentication. The vendor may also provide requirements to application owners to show what instructions on how to perform certificate validation. vulnerabilities exist in current systems and how However, nothing is provided on how to integrate the the use of PKI can help to mitigate them. authenticated identity information from the certificate • Define business case benefits for PKI in addition with access control to a database or other back end to the “better security” case. Because PKI component. acceptance has been primarily in the security community, explanations for why to integrate Training targeted at developers on how to integrate public key technology tend to be heavily security PKI into real-world applications should become focused. The business case for PKI, including much more widely available. more efficient user management, decreased password management, and new functionality 5 Conclusion capabilities, should be more clearly stated. As the DoD has rolled out PKI, it has experienced Getting the acceptance of application owners is a technical challenges. However, PKI has been more critical step in showing a return on investment in successful than many technologies in meeting the PKI. However, most application owners will not scalability demands of the DoD enterprise. By commit to enabling existing applications until the integrating certificate issuance with existing users have digital certificates. DoD applications that personnel processes, the DoD PKI has been able to made initial investments in using PKI in the late perform in-person identity verification to over three 1990s all delayed public key enabling because of the million users. Technology challenges have been met inability of their internal DoD users to register for using a combination of redundant systems and certificates. Now that the DoD has invested customized interfaces developed by DoD, contractor, resources to issue certificates to eligible users, these and vendor personnel working together. The only and other applications are finally beginning the basic building block of PKI that has not scaled transition to using public key technology. successfully is the CRL. However, the DoD is working to overcome this barrier through the use of 4.3 The Developers OCSP. Better training is needed to assist developers The DoD PKI rollout has also encountered issues in public key enabling. surrounding the enterprise nature of PKI. PKI implementation has required that existing business Ultimately, the success of PKI is dependent on process problems be resolved prior to the success of developers performing system integration to public PKI. key enable applications. DoD applications usually The more difficult challenges have been in getting involve some components, such as web servers, that acceptance from the user, application owner, and have native support for some PKI capabilities and developer communities. A primary reason for this other components that do not support PKI. Public issue is the lack of good training available targeted key enabling, therefore, can require upgrading specifically to the interests of these communities. software to later versions that support required The DoD is committed to continuing down the path of PKI deployment and public key enabling of applications. The implementation of PKI is a long term investment, since application owners do not want to commit to using certificates until they believe that their user population has the capability to get certificates. Unfortunately, the return on investment in PKI does not become measurable until applications have started to use the technology. Staying the course has presented challenges, but the potential of public key technology, both in current architectures and in the next generation Net-Centric environment, is critical to meeting the DoD’s information assurance goals and improving its business processes. 1 “Guidelines for Enabling Smart Card Logon with Third-Party Certification Authorities,” Microsoft Knowledge Base Article 281245. http://support.microsoft.com/default.aspx?scid=kb;en -us;281245 2 “Functional Requirements for Path Validation Systems,” Path Validation Working Group, Draft Version 0.8, March 2004. http://www.cio.gov/fbca/pdvalwg.htm Observations from the Deployment of a Large Scale PKI Rebecca Nielsen Booz Allen Hamilton 1 Agenda  DoD PKI Architecture  CA Scalability Managing the “I” in PKI  Hardware and Software Maintenance  Personnel Technology Challenges Organizational Challenges Conclusions 2 The DoD PKI Architecture Key Escrow Root CA Key Recovery Database Agents Directory Global Directory Service Subordinate CAs Relying Registration Parties Authorities Issuance Portals Subscribers 3 Functions performed by Certification Authorities  Validating credentials of trusted personnel Root CA  Publishing certificates  Generating Certificate Revocation Lists (CRL)  Revoking certificates Subordinate CAs  Responding to requests to search for certificates or groups of certificates Take  Take into into account account all all of of the the required required tasks tasks when when developing developing architecture architecture requirements requirements 4 CA Hardware and Software Maintenance  Subordinate CAs are operational for six years, three of which they actively issue certificates and the second three they Root CA continue to issue CRLs  Hardware and software product life cycles are significantly shorter Subordinate CAs  Maintenance costs increase when products are no longer supported by vendors PKI  PKI cycle cycle times times are are significantly significantly different different than than hardware hardware and and software software cycle cycle times times 5 Certificate Key Lengths  Over time, requirements for longer key lengths (512-bit, 1024-bit, 2048-bit, etc.) and support for key lengths changes Certificate  Three year certificate validity period means three year migration requirement once a change to a new key length has been tested 6 Certificate Profile Requirements Microsoft Windows Logon – CRL Distribution Point is Present Certificate – Key Usage set to Digital Signature – Extended Key Usage Contains Smart Card Logon Object Identifier – Subject Alternative Name Contains User Principal Name of the Format user@name.com Federal PKI Path Discovery and Validation Working Group – Authority Information Access 7 Smart Card Technology Common Access Cards are valid for three years Common Access Card Current card uses a 32k chip to store – Java applets – Certificates – Limited user information Additional requirements have been identified for better security protections, additional certificates, and other user information are driving an upgrade to a 64k card Card refresh times require three years to fully phase in new capabilities 8 Personnel Software rollout – Required new roles and new responsibilities Registration – Required new training Authorities – Limited success Common Access Card Rollout – Used existing card issuance personnel – Modified existing processes – Tied certificate issuance to ID card issuance – Certificates issued to over 3 million people Integrating  Integrating PKI PKI rollout rollout with with existing existing processes processes is is aa requirement requirement for for success success 9 Agenda Managing the “I” in PKI  Certificate Status Checking Technology Challenges  Key Recovery Organizational Challenges Conclusions 10 Certificate Status Checking – Certificate Revocation Lists Benefits – Minimum set of data for identifying revoked certificates CRL – Digitally signed by the CA so transmission mechanism is not required to be published Issues – Limited support for automated CRL downloading – Differences in treatment of validity of CRL after NextUpdate time – Scale of DoD PKI (over 9 million certificates) results in large CRLs (40 megabytes) Checking  Checking certificate certificate revocation revocation status status is is one one of of the the most most difficult difficult technical technical challenges challenges of of PKI PKI 11 Certificate Status Checking – CRL Alternatives Partitioned CRLs – CA divides certificates into blocks of a preset size based on CRL certificate serial number – CA issues one CRL for each block – Applications that do not use CRL Distribution Points do not support the use of partitioned CRLs well Delta CRLs – CA issues a full CRL once or periodically, then only issues delta CRLs that contain additional revocations – Delta CRLs are significantly smaller than full CRLs – No single CRL can be considered an authoritative source 12 Certificate Status Checking – Online Certificate Status Protocol The DoD PKI is deploying an infrastructure to respond to OCSP requests from applications across DoD networks CRL Benefits – Provides responses for specific certificates instead of all certificates – Offloads revocation checking to dedicated resources Issues – If OCSP uses CRLs, it does not solve the latency issue – Application relies on signature of OCSP responder instead of CA signature 13 Encryption Private Key Recovery Issue – Key recovery system was designed to be personnel intensive to Key Escrow Database support third party key recovery – Use of hardware tokens means that users lose access to their own encryption keys when the card is renewed – Manual system is too time intensive to support recovery of an individual’s own keys Key Recovery Agents Resolution – Develop an automated process for users to present their new certificates to authorize recovery of their own old keys The  The person person most most likely likely to to need need key key recovery recovery capability capability is is the the subscriber subscriber 14 Agenda Managing the “I” in PKI Technology Challenges  The Users  The Managers Organizational Challenges  The Developers Conclusions 15 Getting User Buy-In Provide training from the user’s perspective, not how the technology works Target opportunities for providing additional functionality or Subscribers shortening process cycle time Ensure users have all of the tools to be able to use certificates Train help desk staff to address PKI issues Provide  Provide users users with with new new capabilities capabilities that that help help them them to to get get their their jobs jobs done, done, not not just just PKI PKI certificates certificates 16 Using PKI Requires Enabling Applications Management of applications is decentralized – Integrating public key technology into applications requires many decisions by many application owners Relying Parties Resources for public key enabling are the same as resources for system maintenance, hardware and software upgrades, or adding additional functionality Application owners are resistant to public key enabling if their user population does not yet have certificates 17 Getting Management Buy-In Ensure that published policy is consistent with overall organizational goals for integrating public key technology Relying Provide direction for requesting funding as part of the Parties standard budget cycle Use specific examples when presenting security requirements to application owners Define business case benefits for PKI in addition to better security – or show business benefits of better security Application  Application owners owners need need policy, policy, budget budget guidance, guidance, and and aa business business justification justification for for adopting adopting PKI PKI 18 Getting Developer Buy-In Few individuals understand both PKI and its impact on application architectures Available training is limited Relying Parties – PKI training tends to cover how to stand up and operate a CA – Web server instructions cover how to install server certificates and turn on client certificate-based authentication – OCSP providers cover how to perform certificate validation Training for how to integrate certificate information with back end access control systems is not available Better  Better training training is is needed needed to to assist assist developers developers in in public public key key enabling enabling 19 Agenda Managing the “I” in PKI Technology Challenges Organizational Challenges Conclusions 20 Conclusions  Rollout of PKI across the DoD has been generally successful  Technology challenges have been met with a combination of redundant systems and customized interfaces  Certificate revocation checking is being addressed with the rollout of OCSP responders across the network  Successful PKI implementation has required resolution of existing business process problems  Better training targeted at users, managers, and developers is needed to get the use of PKI integrated into applications 21 Ceremony Analysis Carl Ellison Microsoft 20 April 2005 Distributed System w/ Security Carol Alice Bob A B C D Design Process Carol Alice Bob A B C D The Real (Full) Protocol Carol Alice Bob A B C D No, THIS is the Protocol !!!! A B C D OK, this is a Ceremony Carol Alice Bob A B C D Ceremony  Protocol HTTPS / SSL / TLS Web Site User HTTP(S) PC a b Establish Channel c d e f HTTPS MITM Protocol Legitimate MITM User HTTP(S) HTTP(S) PC Channel Setup b a c d HTTPS MITM Ceremony Legitimate MITM User HTTP(S) HTTP(S) PC a b Channel Setup d c e f g HTTPS Example Phishing S/MIME Ceremony Sender Recipient PC PC a b c e d f S/MIME Message S/MIME Reply S/MIME Ceremony Concerns Sender Recipient PC PC a b c e d f An idea for Instantaneous Secure Enrollment Marco “Kiko” Carnut 4th PKI R&D Workshop WIP session NIST, Apr/2005 The Client’s CA • Client’s CA Root CA • Private key generated on demand by the main CA Main CA • But it’s not released until after the user’s identity is cheched Kiko [CA] • Restricted to issuing one cert only (clients should verify this) Kiko [Client] • The client app must consider my client cert as trusted even if it’s chain is incomplete. •Many don’t but... well, Kapanga does • Server web sites accept such incomplete/invalid certs by grant them only “guest-level” access • Most apps will consider their digital sigs invalid at this point, just as we want Authorization  After the CA properly identifies the user according to its policies, we release the Client’s CA on a key server  The client and everyone else fetches it  Client must enforce extra restrictions for the “single cert principle” - I’ve been using:  Kiko’s CA DN == Kiko’s Client DN  Kiko’s CA Serial == Kiko’s Client Serial  Kiko’s CA is a CA (basicConstraints:CA=TRUE)  Kiko’s Client is a Client (basicConstraints:CA=FALSE)  Now people will be able to trust my cert  Performance: kinda bad, because the CA must generate a new key  Revocation: we can have a small, single-serial CRL  No large CRLs anymore Thank you! Questions? Real Protection against Real Digital Threats kiko@tempest.com.br Modeling Strength of Security & Its application in PKI Ho Chung1, Clifford Neuman2 April 2005 1 Computer Science Department, University of Southern California 2 Information Sciences Institute, University of Southern California Introduction to SoS  What is the Strength of Security (SoS) model ?  A way of thinking about security such that the relationship of the strength of security is viewed in multiple dimensional way  The dimension is defined as a basic attribute (or a set of attributes) for measuring the strength of security  SoS model is based on the relation theory  E.g. Hasse Diagram, Lattice Structures 2 SoS model is based on the Relation Theory a  Let X={a, b, c, d, e} and a relation R on X is   Assume that the Strength of b Authentication on X is shown as the figure on LHS c d  E.g. 1. a  b  c  e e  E.g. 2. c and d are incomparable  E.g. 3. GLB ({c, d}) = e SoS with Lattice Structure  E.g. 4. LUB ({c, d}) = b 3 Applying SoS into the PKI World  In PGP, the strength of security depends on:  Dimension 1. Strength of protection of the token  Dimension 2. Strength of name-token binding  Dimension 3. Strength of token claimed by the holder  Dimension 4. Strength of algorithm 4 Traditional model - Strength of Tokens  NIST’s security model for cryptographic tokens (e.g. hierarchical and total ordering) Hard crypto token (e.g. H/W device storing keys) One-time password device Soft crypto token (e.g. keys stored on disk) Password  This is a single-dimension based approach.  What happens if we extend it to multi-dimensions? 5 Developing of SoA – Strength of Tokens Hard token One-time password device token with PIN or biometric I/F (w/ expiration) with PIN or biometric I/F (w/ expiration) One-time password device token without PIN One-time password device or biometric I/F (w/ expiration) token with PIN or biometric I/F (w/o expiration) Soft token encrypted with strong password Strong password (w/ expiration) w/ expiration Soft token encrypted One-time password device token with weak password without PIN or biometric I/F (w/ expiration) (w/o expiration) Soft token encrypted Strong password with weak password w/o expiration (w/o expiration) Weak password Soft token encrypted w/ expiration Weak password with strong password w/o expiration (w/o expiration) Tokens with lattice structures Language based Policy Analysis in a SPKI Trust Management System Arun K. Eamani and A. Prasad Sistla§ University of Illinois at Chicago {aeamani, sistla}@cs.uic.edu Abstract— SPKI/SDSI is a standard for issuing autho- logic, for example retrieve all the principals who were rization and name certificates. SPKI/SDSI can be used able to access a resource R at some point in a time to implement a Trust Management System, where the interval. policy for resource access is distributively specified by multiple trusted entities. Agents in the system need a There have been a string rewriting system [CEE+ 01] formal mechanism for understanding the current state of policy. We present a first order temporal logic, called FTPL and a push down system(PDS) [JR01] to model for specifying properties of a given SPKI/SDSI policy state. certificate analysis problems in a SPKI/SDSI framework. We also present algorithms to check if a SPKI/SDSI policy We propose that temporal logic be used as a language to state satisfies a property specified in FTPL. specify the issues of authorization, naming and validity. The policy analysis problem would be specified as a temporal logic formula f and we evaluate the formula I. I NTRODUCTION on a given set of certificates C and a particular time A. Motivation and Use of the Language instance t. The formulas of the logic could be interpreted not only to evaluate the truthness of a statement but also SPKI/SDSI (simple public key infrastructure/simple to reason about the state of the system by finding all distributed security infrastructure) is a mechanism instantiations of free variables which would make the for specifying policy in a distributed access control formula true in the given state of system at a particular system [EFL+ 99], [Ell99]. With standardized semantics instant of time. it can also be viewed as a Trust Management Language [BFK99]. There has been much work done In access control models the usual analysis consists on analyzing fixed a priori defined properties of such of safety analysis [HRU75]: does there exist a reachable an authorization system [JR01], [CEE+ 01]. In this state where a untrusted principal has access to the paper we introduce a language based on general resource? A state in the system corresponds to a set purpose temporal logic for specifying properties of of signed policy statements i.e certificates. We change such a system. This language, called FTPL: First the policy state by adding or deleting a certificate. order Temporal Policy analysis Logic, could be used Li et al [LWM03] propose security analysis where by the agents to reason about the state of the policy. the state can change in a restricted manner. Security Such analysis is useful for understanding the current analysis is a study of security properties such as safety, state of policy, auditing the past policy statements, to availability, containment etc. Availability requires that point out any violations in trust between agents and in every reachable state a particular principal will be for aiding policy refinement/management. We present able to access a resource. Containment requires that efficient methods for automatically checking if a given in every reachable state if a particular principal has a SPKI/SDSI certificate set satisfies a policy question property, say being able to access a resource, then that specified in the logic. The logic that we use is an principal also satisfies a condition, like being member extension of the standard real-time temporal logic of a particular role. The above type of analysis is useful extended with quantifiers over the principals in the to understand how the current policy state can evolve. system. Many important properties such as the following can be expressed in our logic - can two principals K1 We propose policy analysis in distributed access and K2 access the resource R simultaneously at some control models, where we analyze properties of a point in future? We can also specify queries in this particular policy state. We consider a policy state as § This research is partially supported by the NSF Grants CCR- consisting of a set of policy statements each labeled with 0205365and CCR-9988884 a validity interval. Each policy statement is valid during the time interval associated with it. At any point of time The logic we propose would provide the resource only a subset of the given set of certificates are valid. administrator with a formal and a high level mechanism Policy analysis can also be viewed as a special case of for specifying policy properties. The language could security analysis where all the possible state transitions also be useful for the other types of users, like a are know in advance, given that certificate issuers client to reason about properties such as “is there an specify the time period during which the certificate authorization chain leading to the client from a particular is valid. We can reformulate the problems of security principal?” etc. analysis to reason over time instead of reachable states. For example the availability property could be restated The paper will consist of five other sections, section as: at all times in future does a principal K have access [2] presents short description of related work. Section to a resource R. While, for practical reasons, we may [3] consists of introduction to SPKI/SDSI and previous want to reason about bounded availability: at all times models for certificate analysis problems. Section [4] will during a time interval, say a school semester is a student consist of our proposed logic and examples of policy K able to access the school ftp server R. problems specifiable by the language and section [5] will contain algorithms to evaluate the formulas of the logic. In a SPKI/SDSI system, given certificates containing Section [6] consists of conclusion and future work. validity intervals, authorization and name relationships vary with time. In a delegation based system where II. R ELATED W ORK multiple agents make policy statements regarding access There are other logics for SPKI/SDSI which model of a particular resource, no agent is aware of the overall the name resolution, authorization and other features of state of the policy. There being a large number of policy SPKI/SDSI: Martin Abadi’s logic to model local name statements, manual analysis is not an option. Many spaces of SDSI [Aba97], Halpern and van der Meyden’s policy specification languages including SPKI/SDSI Logic of Local Name Containment to characterize cannot specify constraints such as negative credentials, SDSI name resolution which was extended to deal with mutual exclusion, etc. necessitating a mechanism to other SPKI issues like revocation, expiry dates, and make sure that agents didn’t make policy statements tuple reduction [HvdM01]. Ninghui Li [Li00] proposes which violate the unspecifiable constraints. In addition, a logic program to describe the name resolution analysis of current policy state is useful to formally algorithm which also handles authorization certificates reason whether the current policy state satisfies user and threshold subjects. The purpose of our logic is defined properties and to gain knowledge for making neither to model the features of SPKI/SDSI nor to decisions about changing the current policy state. Based provide for its semantics but for policy analysis. Jha on current policy state, we can also reason about issues and Reps [JR01] propose using temporal logic to reason of authorization and naming in future time. about certificate chain derivations in a given SPKI system, while we propose using temporal logic as a We also propose policy audit, where we check for language for specifying certificate set analysis problems policy violations over a set of all the policy statements involving authorization, naming and validity. which were valid during the time of audit. In access control audit, the problem is of type: did principal K There have been many languages, logic and semantic access a resource R?, while in policy audit we check frameworks to express authorization policy in a whether a principal K had permissions to access a distributed system. Datalog and its variants seem to resource R? or whether principal K1 gave authorization be the language of choice to specify authorization regarding a resource R to principal K2 . Policy audit policy [LM03]. A specific class of distributed access is a means to ascertain whether trusted agents were control systems attracting much attention are the Trust really trustworthy with regards to policy specification. Management Systems [BFK99], [BFIK99]. The concept By suitably shifting the timeline, we can use FTPL for of Trust Management is that there exists a standard purpose of reasoning about current policy state as well mechanism for expressing the access control policy as for policy audit. For purposes of policy audit, we and also a standard method to verify that an access collect the set of all policy statements corresponding to request complies with the policy. This is called “Proof the time of audit and evaluate the formulas of the logic of Compliance”. SPKI/SDSI was not intended by the over the static collection of policy statements labeled authors to be a Trust Management System in that Proof with validity periods. of Compliance can be application dependent, but it can be viewed as a Trust Management System with standardized certificate chain reduction rules [EFL+ 99]. trusted to issue certificates bearing their signature. Though lot of work has been done in specifying policy and checking whether an access request is compliant In SPKI/SDSI resource owners can delegate access with the policy in a distributed access control system, rights to trusted entities and they can issue certificates not much literature exists regarding a language based authorizing others, leading to a chain of certificates from mechanism for detailed analysis of policy beyond simple the resource owner to the end user. In a SPKI/SDSI authorization problems. To our knowledge FTPL is the system principals and resources are identified by their first such language for high level policy analysis in not corresponding public keys. We can still associate names just a SPKI/SDSI system, but in the distributed access with the principals. Every principal has a local name control framework. While we give a logic to formulate space and the principal is free to define local names in policy analysis problems in the context of SPKI/SDSI his domain independent of others. For example for a we feel that full fledged languages for policy analysis UIC student John, university may be defined as KU IC , in other distributed access control systems and trust while for a UIUC student Jim, university may be defined management systems are of much use to the users of as KU IU C . KU IC , KU IU C are the public keys of the the system. universities UIC and UIUC respectively. Public keys being unique throughout the system, a name qualified We give a list of specifiable problems that could by the public key of the principal defining the name, is be of interest in SPKI/SDSI policy analysis including also unique. some given by Jha and Reps [JR01]. The problems they Definition 1: An identifier is a word over a given list can be qualified by time. For example Authorized alphabet. The set of identifiers is denoted by I . The set Access 1:“Given resource R and principal K , is K of keys is denoted by K. authorized to access R?”, can be more specifically Definition 2: A local name is a sequence consisting written in the context of time as:“Given Resource of a key followed by a single identifier. A local name K R and principal K is K authorized to access R at friend may be defined as Kbob , Kj im ,... etc a particular instant of time, or at some point in a There is another kind of name in SPKI/SDSI called time interval?” While Jha and Reps provide a lattice extended name which increases the level of indirection based time structure which can be used to model such in the naming scheme. problems, we give a logic based formalism to specify Definition 3 : An extended name is a sequence con- such problems. sisting of a key followed by two or more identifiers. An example of an extended name is K brother friend, where the meaning of friend would be evaluated in the context III. SPKI/SDSI of K 0 s brother. Definition 3: A Name is either a local name or an A. Introduction extended name. We denote the set of all names as N . SPKI and SDSI are certificate based mechanisms Definition 4: A Term is either a key or a name. We for authorization and naming in distributed systems use T = K + N to denote set of all terms. respectively. SPKI 1.0 : simple public key infrastructure, Definition 5: We define a fully qualified name also to was a mechanism for expressing authorizations and mean a public key or a local name or an extended name. delegations, where it was proposed that permissions be given directly to the public keys of entities. The most important contribution of SDSI: simple distributed B. Certificate Structure security infrastructure, was to create local namespaces There are two types of certificates or certs in distinguished by the unique public key of the entity SPKI/SDSI: name certs and authorization(auth) certs. defining the names, instead of trying to create a The function of a name cert is to define a local name as globalized namespace. Features of SPKI 1.0 and SDSI another term. Only the principal, in whose namespace 1.0 were integrated into SPKI/SDSI 2.0 [EFL+ 99]. the local name is defined, may issue the corresponding In the future if we say SPKI we mean SPKI/SDSI name certificate. In an auth cert a principal can grant or 2.0 unless mentioned otherwise. One of the features delegate permissions regarding accessing a resource to of the SPKI is that every principal is free to issue another term. We now describe the logical structure of certificates signed by himself unlike in X.509 PKI the SPKI/SDSI certificates. framework [ADT02] where there are separate set of There are four fields in a name certificate (K, A, S , V ) principals called certificate authorities(CA) who are which is signed with the private key of the issuer: K −1 . K is the public key whose namespace is being receives a set of certificates it verifies them for integrity considered, A is an identifier in I and S is an element and stores them in an unsigned form called the tuples. of T , i.e. it can be another public key, or a local name We use the terms certificates and tuples interchangeably or an extended name. S is the term implied by the as far as there is no confusion. local name KA . V is a validity specification which Consider a certificate issued by K1 to a key K2 with states the validity condition for the certificate. The basic authorization actions A1 and and validity specification validity specification is of form [t1 , t2 ] where t1 , t2 are V1 , suppose delegation bit D1 is also true. Then the absolute time constants. The certificate is said to be valid certificate is logically represented as 5-tuple from time t1 to t2 . If either t1 or t2 are not given we assume −∞ or +∞ respectively. Validity specification C1 : (K1 , K2 , D1 , A1 , V1 ) could also be a certificate revocation list or an online Given D1 to be true, let K2 delegate authorization check [CEE+ 01]. In our model of SPKI we consider a actions A2 to subject S2 , with validity condition V2 and validity specification to be a certain time period in the delegation bit D2 . interval 0 to ∞. The authorization certificates consist of five fields C2 : (K2 , S2 , D2 , A2 , V2 ). (K, S, D, E, V ) signed by the private key of the According to the tuple reduction rules the result of issuer: K −1 . The main purpose of an SPKI authorization composition of the certificates C1 and C2 in that order certificate is to grant or delegate a set of authorization is another certificate C 0 equivalent to the chain actions as specified by E to the subject S ∈ T . K is the public key of the certificate issuer. C1 ◦ C2 ≡ (K1 , S2 , D2 , AI nter sect(A1 , A2 ), S is the Subject which can be either a key or a name. D is the boolean delegation bit which controls the V I nter sect(V2 , V2 )). delegation rights. These equivalent certificates can also be used as a regular E is the set of authorization rights which are granted certificates in the SPKI system and are called Certificate or delegated to the subject by the issuer. Note that au- Result Certificates (CRC). thorization actions have address of the resource encoded AI nter sect() is the intuitive intersection of authoriza- in them. In our logic when we say read we mean read tion action sets. Howell and Kotz [HK00] note that the of a particular resource R defined in the context. intersection may not always be well defined. For the pur- V is the Validity specification and the observations pose of our logic we consider authorization actions to be made above for name certs are applicable here also. simple constants. Date range intersection V I nter sect() Delegation bit D implies that when the bit is set to one is the intersection of corresponding validity intervals. then the subject can access and also delegate the rights specified by set E to other users in the system, if the bit D. Models for SPKI Certificate Analysis. is zero then the subject only gets the right to perform actions specified by E , but cannot further delegate these There are two primary models for tuple reduction rights to any other user. problems, one is the string rewriting model of Clarke et al [CEE+ 01] and the other is the push down sys- tem(PDS) based semantics of Jha and Reps [JR02]. We C. Tuple Reduction present the PDS based model of [JR02] In a delegation based distributed access control system 1) Push Down System based Semantics: Jha and the resource owner permits others to specify policy Reps [JR01] model tuple reduction problems as config- regarding the access of the resource. Entities entrusted uration reachability problems in a pushdown system. A with delegation rights further propagate the access rights. push down system is similar to a push down automata This leads to a chain of certificates for accessing a but without the input alphabet. They view the autho- resource. The principal requesting access would present rization problem: can a principal Kp access resource the resource administrator with a requested authorization a R as a configuration reachability problem in the action and a chain of certificates which should prove pushdown automata and use the PDS model checking that the requesting principal has the right to perform the algorithms [EHRS00], [BEO97] to answer the prob- requested action. Given a chain of certificates, one must lem. The configuration of a PDS contains information deduce authorization and validity information from the about the control state and stack state of the PDS at chain. The rules which specify the inference conditions a particular point in the computation. A configuration are called the tuple reduction rules. When an entity of PDS corresponds to a term in a SPKI system. If a configuration GT reaches another configuration GS The symbol ¤ implies permission to delegate while using the state transition rules, then the corresponding ¥ just grants access. The set ∆ of state transitions term T can resolve to term S , defining the “ term reach- contains a transition (K γ ,→ K 0 ω) for every cert rule ability semantics” for the SPKI/SDSI system. PDS State (K γ → K 0 ω). The term K1 A B corresponds to the transition rules correspond to the SPKI/SDSI certificates. PDS configuration hK1 , A Bi, term K corresponds to The PDS formalization is also more expressible then the hK, ²i. When the PDS is in configuration hK1 , A Bi rewriting system of Clarke et al [CEE+ 01] to formulate and there is a state transition rule(cert) K1 A ,→ K2 various certificate analysis problems. We now describe then it goes to configuration hK2 , Bi. The reachability the method to build a push down system from a given relation ⇒∗ defines set of all terms which a given set of certificates and then model the certificate analysis term can resolve to. For authorization derivability, the problems using configuration reachability relation of the PDS configuration is of the form hK, ¤i which means PDS. The primary issues of certificate analysis are that principal K can access and delegate permissions, or of of name resolution and authorization derivability. For the form hK, ¥i which means K can just access. A purposes of the algorithm we convert name certs of form principal K can access the resource R if there is a run (K, A, S, V ) into the rewriting rule KA → S , auth cert of the PDS from configuration hR, ¤i to either of the (K, S, d, E, V ) is written as rule K¤ → S¤ if d = 1 configurations hK, ¤i or hK, ¥i. Whether a term can else as K¤ → S¥ if d = 0. V and E are ignored for resolve into another term can be decided in the PDS now, we consider that each resource has only one type system in time O(n2 LC ) where n is the total number of of access right. keys in the certificate system C, and LC is the sum of A pushdown system is formally defined as a triple lengths of the right hand side(rhs) of all the certificates P = (Q, Γ, ∆), where Q is a finite set of state in the system. Length of the rhs of a cert is the number variables, Γ is a finite set of stack symbols, and of non-key symbols on the rhs of the rule corresponding ∆ ⊆ Q × Γ × Q × Γ∗ is the finite set of state to the cert. transition rules. If (q, γ, q 0 , w) ∈ ∆ then we write (q, γ) ,→ (q 0 , w). The PDS P when in state q and γ We use term reachability semantics of the PDS model on top of stack, uses the above transition rule to goto to define the FTPL semantics. For that purpose we mod- state q 0 , popping γ and writing string w onto the stack. ify the PDS described above by adding an authorization The ,→ corresponds to the rewriting relation between variable v to the system to form a augmented PDS various elements of a SPKI certificate. A configuration P = (Q, Γ, δ, v). The authorization rights a principal of P is a pair hq, wi where q ∈ Q and w ∈ Γ∗ . Here grants to another principal are computed as the side- q denotes the control state and string w the stack effects of the run of the PDS using the authorization state. The set of all configurations is denoted by G . variable v . At the start of a computation v is initialized Corresponding to the transition relation of the PDS to A, the set of all authorization rights for the resource states we have the (immediate) reachability relation being considered. Each auth cert rule is labeled with of the configurations. If (q, γ) ,→ (q 0 , w) then for all the authorization rights granted to the subject of the v ∈ Γ∗ , hq, γvi ⇒ hq 0 , wvi, i.e. configuration hq, γvi is cert. Accordingly, we also label the corresponding state said to be the immediate predecessor of hq 0 , wvi. The transition rule in δ . In the PDS P whenever we go from reflexive transitive closure and the transitive closure of one configuration to another configuration using a state the immediate reachability relationship(⇒) are denoted transition rule labeled with a set of authorization rights by ⇒∗ and ⇒+ respectively. A run of a P DS is E, we update the authorization variable v as v = v ∩ E . a sequence of configurations c0 , c1 , ...cn such that If the PDS goes from configuration hK1 , ¤i to hK2 , ¤i ci is an immediate predecessor of ci+1 . The run of with the value of v as A1 at the end of the run, then a PDS corresponds to a SPKI certificate chain reduction. K1 directly/indirectly delegates to K2 the authorization rights A1 . Given a set of certs C with principals(keys) represented by K and identifiers by I , we construct a IV. L OGIC FOR P OLICY A NALYSIS PDS PC (Q, Γ, ∆) as follows. The set of control states is the set of keys, Q = K. A. Definition of the Logic Note that we only analyze authorization problems We define a polyadic First order Temporal Policy concerning a particular resource which is identified by analysis Logic (FTPL) as a language for specifying prop- a special key R in K . The stack alphabet is set of erties of a SPKI/SDSI certificate system. The formulas of identifiers and the delegation symbols, Γ = I ∪ {¤, ¥}. the logic are to be evaluated on a semantic model of the SPKI/SDSI system. The policy analysis problem would resource R. be specified as a FTPL formula f which is interpreted The syntax of the logic is inductively defined as on a given set of certificates at a particular instance of follows: time. Users can choose application dependent semantics for the language, but we use the standard tuple reduction 1)) If i ∈ K ∪ V , j ∈ T ∪ V , d ∈ {0, 1} and e ⊆ A semantics [CEE+ 01] with the view of SPKI as a trust then authoriz e(i, j, d, e) is a FTPL formula. management system. The constructs of the logic deal 2) If p ∈ N and q ∈ T ∪ V then resolve(p, q) is a with the issues of authorization, naming and validity. FTPL formula. Though we model time as discrete in this paper, we can 3) If f and g are formulas of the logic, then ¬f and easily extend FTPL to interpret over continuous time. f ∧ g are also FTPL formulas. The authorization reachability issue is modeled by the 4) If f and g are formulas of the logic Xf, f U[t1 ,t2 ] g , predicate authoriz e(i, j, d, e), called the authorization are also FTPL formulas. reachability predicate, where i is a key or a variable 5) If f is a formula of the logic then (∃if (i))is also and j is a fully qualified name or another variable. a FTPL formula. The components of authorize predicate d, e specify the delegation and authorization rights respectively. The A variable i is bound in a formula f , if every boolean delegation control d ∈ {0, 1}, with 1 implying occurrence of i in f is in the scope of a quantifier permission to access and delegate and 0 just granting over i. If i occurs in f and is not bound then we access. The authorization control e is a subset of a call i a free variable of f . We use free variables in set of constants A, which specifies the set of autho- the formula to formulate queries over a SPKI system. rization actions for a particular resource. The predicate The formula will return a set of evaluations which authoriz e(i, j, d, e) is true at a particular instance of when substituted for the free variables would make time t with respect to a given set of certificates C, the logical formula true in the context of the given if there is a chain of certificates, where the principal certificate system C at a particular instant of time t. denoted by i directly/indirectly transfers the rights d, e For a formula f , let f ree-var(f ) denote the set of free to the principal or name denoted by j . Name certificates variables of f . An evaluation say ρ for the formula f is are not just mechanisms to resolve names to principals a mapping from f ree-var(f ) to the set of principals, but can also be used to delegate permissions [Li00]. To ρ : f ree-var(f ) → K. We extend the domain of ρ to reason exclusively about name resolution we define the (f ree-var(f ) ∪ T ) so that for every T ∈ T , ρ(T ) = T . predicate resolve(p, q) where p is either a local or an An interpretation for a formula f is a triple (C, t, ρ) extended name and q is either a fully qualified name where C is a set of certificates, t ≥ 0 is a time instance or a variable. The predicate reasons whether the name and ρ is an evaluation. denoted by p resolves to the term denoted by q using the name certificates given in C . The type of a variable We give the semantics of a formula f over an in- in case of both authoriz e and resolve is the set of terpretation (C, t, ρ). For any certificate C let C.val be all principals in the system. The only atomic formulas the validity time interval of C . For a given set C of of the logic, are the authorization reachability predicate certificates and time t, let Ct = {C ∈ C|t ∈ C.val}. Ct authoriz e(i, j, d, e) and the name resolution predicate denotes the set of certs valid at time t and PCt (Q, Γ, δ, v) resolve(p, q). The rest all formulas are combinations denotes the PDS constructed from the set of certs Ct as of the predicates with the associated FTPL operators. described in previous section. The operators of the logic consist of the usual boolean We define the satisfiability relation |= between an connectives ¬ and ∧, the temporal nexttime operator interpretation and a FTPL formula as follows: X, the bounded until operator U[t1 ,t2 ] where t1 , t2 are positive integers and t1 ≤ t2 , the principal quantifier (C, t, ρ) |= authoriz e(i, j, d, e) if the PDS ∃ where the universe of discourse is the set of princi- constructed from set of certificates Ct , PCt can go from pals(keys) present in the certificate system C, over which configuration hρ(i), ¤i to the configuration hρ(j), ¤i, the formulas of the logic are interpreted. These are the with authorization variable v ⊇ e, at the end of the basic operators. We assume we have set V of variables. computation, when d = 1 i.e. hρ(i), ¤i ⇒∗ hρ(j), ¤i. All the variables range over the set of principals present If d = 0 the PDS PCt can reach either the above in the given certificate set C. Let K,T be the set of keys configuration or the configuration hρ(j), ¥i. and terms present in certificate set C respectively and Note that if the key ρ(i) directly/indirectly issues term A be the set of authorization actions for a particular ρ(j) with greater delegation and authorization rights than specified by d and e respectively, the authorize authorize(R, x, 1, {r}), where x is a free variable, predicate still holds true. denotes a query which returns all the principals x who have the permission to delegate right r of the resource (C, t, ρ) |= resolve(p, q) if the PDS PCt can go R at the current instance of time. from configuration corresponding the name p, to the configuration corresponding the term ρ(q). B. Using the Logic to analyze the state of a given SPKI system (C, t, ρ) |= ¬f iff (C,t, ρ) 2 f All the formulas are evaluated in the context of a given certificate set C and with respect to a particular (C,t, ρ) |= f ∧ g iff (C,t, ρ) |= f and (C,t, ρ) |= g resource R unless otherwise specified. Constructing the required set of certificates C for evaluating a (C,t, ρ) |= Xf iff (C,t + 1, ρ) |= f . formula in a distributed environment is non-trivial. Xf is true at an instance of time t iff f is true in the Like others [CEE+ 01], [JR02] we assume that we next instance of time t + 1. have the required set of certificates to evaluate the formulas of the logic. Distributed database lookup and (C,t, ρ) |= f U[t1 ,t2 ] g iff ∃t0 ∈ [t + t1 , t + t2 ] such goal-based certificate discovery methods seem to be that (C,t0 , ρ) |= g and ∀t00 : t ≤ t00 < t0 (C,t00 , ρ) |= f . promising approaches in retrieving the required set of f U[t1 ,t2 ] g is true at time t, iff formula f is true from certificates dynamically, especially for the SDSI part of time t to t0 , where at t0 , g will be true and t0 − t should the system [LWM01]. be within bounds of [t1 , t2 ]. From the perspective of a resource administrator a (C,t, ρ) |= ∃if (i) iff there exists an K1 ∈ K such practical guideline seems to be to cache all the certificate that (C,t, ρ0 ) |= f (K1 ) where ρ0 is a restriction of chains which are presented as a proof of compliance by the domain of ρ to (f ree-var(f (K1 )) ∪ T ). the access requesting clients. The resource administrator may cache these certificates in a secure storage and For convenience of expression we introduce derived use the FTPL logic as a means of offline Policy Audit. operators ∨, ♦, ¤, ∀, / which are extensions of the basic Though the view that certificates don’t exist till they are FTPL operators. used seems to be suited for policy audit, it can have unanticipated results as we show with an example later f ∨ g ≡ ¬(¬f ∧ ¬g) in the section. The language FTPL can be used in two ♦[t1 ,t2 ] f ≡ T rue U[t1 ,t2 ] f analysis modes with respect to time. By defining the origin of time “ 0” to be current time instance, we can ¤[t1 ,t2 ] f ≡ ¬3[t1 ,t2 ] ¬f reason about the current state of the policy. For auditing ∀if (i) ≡ ¬∃i¬f (i) a set of policy statements made from a particular time t in the past we can time shift the origin of time to t. ∃i / G f (i) ≡ ∃i(resolve(G, i) ∧ f (i)) We now illustrate the use of language to specify policy ∀i / G f (i) ≡ ∀i(resolve(G, i) ⊃ f (i)) analysis problems. This formula specifies that at every instance during ∨ is the standard propositional operator. ♦, ¤ are the the period [t1 , t2 ] atleast one principal in the set defined standard temporal logic operators. ∀ is the universal by fully qualified name G has ‘w’ access to resource R quantifier. / is the name resolution operator. ♦[t1 ,t2 ] f (Group availability property): states whether f is true during any time instance from t1 ¤[t1 ,t2 ] ∃i / G authorize(R, i, 0, {w}) to t2 . ¤[t1 ,t2 ] f states whether formula f is true through- out time interval t1 , t2 . Intuitively the name resolution This formula specifies whether a blacklisted principal operator / resolves a name (local or extended) to its KB ever had ‘read’ access to a resource R during the principals according to the SDSI name resolution prin- time of audit [0, ta ]. Here “ 0” refers to the start time of ciples and then evaluates the formula over the restricted the audit, and “ ta ” the end time of the audit: domain. ♦[0,ta ] authorize(R, KB , 0, {read}) Given a formula f with free variables and a set of This formula specifies that principal K will be able certificates C and a time instance t, we interpret the to delegate ‘read’ right for the file R in future: formula f as a query returning a set of tuples, which are evaluations satisfying the formula f . For example ♦[0,∞] authorize(R, K, 1, {read}) This formula specifies that given resource R and name different set of certificates for different subcomponents G, there is an authorization chain granting G permissions of the formula. to perform action ‘w’ on R at current time: This query returns all the principals who will be excluded from performing action ‘w’ currently on the authorize(R, G, 0, {w}) resource R if all the certificates issued by a compromised This formula specifies that given resource R and name key K , CK ⊆ C are revoked now. G, all the principals denoted by G are authorized to {x| (C, 0, ∅) |= authorize(R, x, 0, {w})}− perform action ‘w’ on R at current time: {x| (C − CK , 0, ∅) |= authorize(R, x, 0, {w})} ∀i / G(authorize(R, i, 0, {w})) Certain problems like “ is there a authorization chain Note that the later formula implies the former, but not from the resource R to a principal K without involving vice versa. the compromised key K 0 ” , are not directly expressible in This formula specifies that both the principals the logic FTPL. By using the above mentioned method K1 and K2 have simultaneous ‘write’ access to a we can still answer such questions. resource R at some time in the future(mutual exclusion): ♦[0,∞] [(authorize(R, K1 , 0, {write})∧ Reasoning about roles in a SPKI system. Li [Li00]states that local names in the SPKI framework authorize(R, K2 , 0, {write}))] can be interpreted as “ distributed roles” . Distributed in This formula specifies that both the principals the sense that they are not specified by a centralized K1 and K2 have ‘write’ access to a resource R at authority in the traditional sense of the roles. Roles are some time in the future: thought of as an abstraction for a set of users and a set of permissions, they can include other roles too [San98]. ♦[0,∞] (authorize(R, K1 , 0, {write})∧ Roles can be implemented in a SPKI system using ♦[0,∞] authorize(R, K2 , 0, {write})) local names by giving permissions directly to local names instead of principals. Principals inherit privileges This formula specifies that a principal belonging to lo- by virtue of being members of a “ local name” . This cal name Kf oo Accountant is directly/indirectly granting approach is useful to simplify policy specification in write permissions for a resource at some point of time many real-world scenarios. We can use FTPL to reason to a principal of local name Kf oo P urchaser (conflict about the interpretation of local name as roles. The of interest). predicate resolve can be used to reason about role membership and role hierarchy specified in a distributed ♦[0,∞] ∃i, j(authorize(i, j, 0, {write})∧ fashion. The following formula specifies that role corresponding local name R2 dominates that of R1 : resolve(Kf oo Accountant, i)∧ resolve(R1 , R2 ) resolve(Kf oo P urchaser, j)) Static separation of duty: This formula specifies that Given resource R , this query returns all the principals two roles R1 and R2 have the same user as a member authorized to perform actions ’r’ and ’w’ on R at time in both the roles at same time. ta : 3(ta ,ta ) authorize(R, x, 0, {r, w}). ♦[0,∞] ∃i((resolve(R1 , i) ∧ resolve(R2 , i)) Where x is the free variable which returns all valuations Containment: This formula specifies that there is a satisfying the above formula. principal not contained by role R having ‘r’ access to a resource P at any point of time: This formula specifies whether principal K1 can ac- ♦[0,∞] ∃i (authorize(P, i, 0, {r}) ∧ ¬ resolve(R, i)) cess resource R before K2 : ¬authorize(R, K2 , 0, {r}) U[0,∞] We can also use FTPL to reason about trust violations in a SPKI system. Consider the following scenario : authorize(R, K1 , 0, {r}) A resource KU niv in a university, which the students All the previous properties and queries assumed that in CS and ECE dept need to have read access, some we evaluate the formula against a single certificate teaching assistants and special students(say research system C. In the following query we need to consider assistants) in CS dept also need to have a write access. But no non-CS student is supposed to have a write certificate has been issued in violation of the policy, that access to the resource. Given that it is not possible certificate has not been used. In this case the serious to specify negative permissions in a SPKI system the problems which arise because of evaluating a formula resource administrator has to trust that the principals on a partial state of the system are due to lack of name with delegation authority will not violate the university certificates. Goal directed algorithms for retrieving the policy. distributed set of SDSI name certificates already exist in the literature [LWM01]. (KU niv , KCSD ept students, {read}, 0, {t1 , t2 }) (KU niv , KE CE D ept students, {read}, 0, {t1 , t2 }) V. E VALUATING THE FORMULAS (KU niv , KCSD ept , {read, write}, 1, {t1 , t2 }) : So that In this section, we give an algorithm that takes a the CS dept admin can give write permissions to certificate system C and a FTPL formula f and outputs a selected TA’s and some special CS students. set of pairs of the form (ρ, t) such that f is satisfied with (KCSD ept , KT A1 , {read, write}, 0, {t1 , t2 }) respect to the evaluation ρ at time t, i.e., (C, t, ρ) |= f . (KCSD ept , KT A2 , {read, write}, 1, {t1 , t2 }) : TA2 can For ease of presentation of the algorithm, we assume give write permission to some special CS students. that there is only one resource and one access right. It (KCSD ept , students, Kstudenti , {t1 , t2 }) : Name can be easily generalized to the case of multiple access Certificate for CS student ’i’ including TA’s and special rights. If f has k free variables, the algorithm actually CS students. computes a relation Rf which is a set of (k + 1)- tuples such that the first k values in each tuple define In the above system the CS admin or TA2 can violate an evaluation ρ and the last value in the tuple is a list of the “ university policy” by giving permissions to a non- time intervals such that for all instances t in these time CS student. intervals (C, t, ρ) satisfies f . Actually, we compute the The university resource admin wants to check whether relations Rg for each subformula g of f . These relations there is a Non-CS student having write access to the are computed inductively in increasing lengths of g . In resource. the base case, g is an atomic subformula which is of the form authorize(i, j, d, e) or is of the form resolve(p, q). ♦[0,∞] ∃i [(authorize(KU niv , i, 0, {write})∧ Recall that for the atomic formula authorize(i, j, d, e), ¬resolve(KCSD ept students, i)] i can be a variable or a key, and j can be a variable or a term. We assume that j is a variable or a key (if j is a Evaluating a FTPL formula on a partial set of term then by introducing new keys and new rules we can certificates. reduce it to a case where j is a key. For example in order In the case where we evaluate the above formula over a to evaluate a predicate authorize(K1 , K2 A1 , d, e) over set of certificates obtained by caching the previous access certificate set C, we add new key K3 and a new rule request chains we may get a false-positive. Consider the K2 A1 → K3 and evaluate authorize(K1 , K3 , d, e) in scenario where TA2 from start uses the following chain the augmented system. The total number of new symbols to get resource authorization, and rules we introduce is bounded by the sum of right [(KU niv , KCSD ept , {read, write}, 1, {t1 , t2 })◦ hand sides of the certificate rules). Similarly we assume that in resolve(p, q), p can be a name and q can be (KCSD ept , KT A2 , {read, write}, 1, {t1 , t2 })] a key or a variable. In the first step of our algorithm, then the name cert validating TA2 to be a student of we compute the relations Rg for the case when g is CSDept is not cached by the resource administrator lead- an atomic formula. In the second step, we compute the ing to a false positive. When the resource administrator relations Rg for the case when g is not atomic. catches a possible policy violation he can use manual In the first step, the algorithm operates as follows. resolution or a goal-directed procedure to confirm the Recall that each certificate in the set C is associated result. The other type of violations are caused by lack of with a valid interval. We assume that tmin and tmax , authorization certs, for example when a principal grants respectively, are the minimum of the beginning points permissions to a blacklisted principal, but the blacklisted and the maximum of the end points of the validity principal doest not access the resource and no chain intervals of certificates in C. Let m be the number involving the blacklisted principal is sent as a proof of of certificates in C. Using the validity intervals of the authorization, then the corresponding formula evaluated certificates, we compute a sequence of increasing times over the cached set of certs returns a false answer. But T0 , T1 , ..., Tl−1 (These sequences can be easily computed this is a benign violation in the sense that though a from the sequence obtained by taking the begin and end times of all the validity intervals of certificates in C and principals in one structure from which the required sorting them in increasing order) and a sequence of sets relations can be computed efficiently. The And-or graph of certificates C0 ,...,Cl−2 such that l ≤ 2m, T0 = tmin , H can be computed directly from C without constructing Tl−1 = tmax + 1 and for each i, 1 ≤ i < l, the set of either of P or G . However, their definition gives a better certificates in C that are valid at every time instance in intuition leading to an easy proof of correctness of the the interval [Ti , Ti+1 − 1] is the same and is given by Ci . algorithm. We can see that the complexity of the above procedure is The given certificate system D is expressed as a set dominated by the complexity for sorting the time points of rewriting rules, the name certs correspond to the and hence is O(m log m). rules of form K1 A → K2 A1 A2 ...An . The auth certs For each i = 0, ..., l − 2 we do as follows. Using correspond to rules of the form K ¤ → K1 A1 A2 ..An ¤. the set of certificates Ci , for each atomic formula g Corresponding to each key K we introduce two symbols of f we do as follows. Consider the case when g is K ¤, K ¥. K# is the augmented set of keys consisting authorize(p, q, d, e). In this case, both p, q are either of the original keys and their associated symbols. a variable or a key. We compute the set E valg,i of evaluations ρ for g such that the following property is Given the set D of cert rules, all the rules will be satisied: if d = 1 then the the PDS PCi can go from the converted to a normalized transition function δ of a configuration hρ(p), ¤i to the configuration hρ(q), ¤i; if pushdown system. The pushdown system P we consider d = 0 then the PDS can go to the above configuration is a three tuple (Q, Γ, δ). Q is the set of states as or to the configuration hρ(q), ¥i. Note that if p is not given below, Γ is the stack alphabet containing identifiers a variable then ρ(p) = p; similar condition holds for and delegation symbols of a SPKI system, δ ⊆ Q × q . If neither of p, q is a variable then ρ is the empty {Γ ∪ {²}} × Q × {Γ ∪ {²}} is the transition function. evaluation; in this case either E valg,i contains the empty δ can have transitions either of type (K1 , A1 , K2 , ²) or evluation indicating the satisfaction of g at every time (K1 , ², K2 , A1 ), which means that PDS can go from instance in the interval [Ti , Ti+1 −1] or it is the empty set state K1 to state K2 either by popping or pushing a indicating the non-satisfaction of g in the above interval. symbol A1 ∈ Γ on top of the stack. ² is the empty string If g is resolve(p, q) then we compute the set E valg,i character. Thus in each transition a symbol is pushed or of evaluations ρ such that the above PDS can go from is popped from the stack and both do not occur in the the configuration corresponding to the name p to the same transition. Let li be the length of right hand side configuration corresponding to the term ρ(q) (recall that of rule i, LD the sum of the lengths of the right hand p has to be a name and q can be a variable or a term; side of the cert rules. also, recall that the configuration corresponding to the Q = K# ∪ {(i, j)| 1 ≤ i ≤ |D|, 1 ≤ j ≤ name of the form K A B is hK, A Bi). `i }, Γ = I ∪ {¤, ¥}. Each rewriting rule is con- Now it should be easy to see how Rg can be calculated verted into a set of four tuples in δ . If we have the from the sets E valg,i for i = 0, ..., (l − 2). Recall that, if i’th cert(name or auth) with length `i as Ki Ai → g has k free variables then Rg is a set of (k + 1) tuples Ki0 m(i,1) ...m(i,`i ) ; Ai , m(i,1) ...m(i,`i ) ∈ Γ, then it will (here k ≤ 2). For each evaluation ρ that appears in at be converted to normalized tuples of set δ as follows: least some E valg,i , Rg has a single tuple whose first k For each K , the PDS when in state K ¤ pushes ¤ onto components give the evaluation ρ and whose (k + 1)st the stack and goes to state K . component is the list of all time intervals [Ti , Ti+1 − 1] (K ¤, ², K, ¤) ∈ δ. such that ρ is in E valg,i . In the above procedure, we defined the sets E valg,i In a state K , the PDS non-deterministically chooses using a PDS PCi . However, we plan to employ a And-or a rule i whose left hand side key is K and and the left graph from which the sets E valg,i can be computed for hand side symbol(identifier or delegation bit) matches all g using a single fix point computation. the symbol on top of the stack, it pops the symbol Now we describe the And-or graph construction for currently on top of the stack and goes to state (i, li ) a set D of certificates. First using the certificate set D, if li > 0 or else if li = 0 to state Ki0 given by the right we first define a nondeterministic normalized pushdown hand side key of rule i. system P, from which we define an equivalent context ( K, Ai , (i, `i ), ² ) ∈ δ. free grammar G, which is converted in to an And-Or graph H. The advantages of using the And-Or graph ( K, Ai , Ki0 , ²) ∈ δ over the PDS model of Jha and Reps [JR02] is that In a state of the form (i, j) it pushes the j ’th identifier we have the reachability relationships between various of the right hand side of the i’th cert and goes to state (i, j − 1) if j > 1, else if j = 1 it goes to the state Ki0 edges is defined as follows. From each node of the form given by the right hand side key of rule i. [p, r, q] there are exactly two edges going to the vertices [p, r] and [r, q]. For each rule of the form Apq → Ars ( (i, j), ², (i, j − 1), m(i,j) ) ∈ δ f or all 2 ≤ j ≤ `i . in G , we have an edge from ([p, q] to [r, s]). For each ( (i, j), ², Ki0 , m(i,j) ) ∈ δ when j = 1. rule of the form Apq → Apr Arq in G , we have an edge from [p, q] to the vertex [p, r, q]. Note that there may be When the PDS is in state of type K and the top of cycles in the graph. the stack symbol is either ¤ or ¥ then it goes to state K ¤ or K ¥ respectively. Now, we compute a function F : V → {T rue, F alse} ¤ ¥ (K, ¤, K , ²) ∈ δ, (K, ¥, K , ²) ∈ δ which is the least fix point that satisfies the following conditions: for each vertex u of the form [p, p], F (u) = We can see that in a SPKI system D a key K1 gives T rue; for each vertex u of the form [p, q] (p 6= q ), F (u) authorization to another key K2 if the PDS P when is the disjunction of all F (v) such that (u, v) ∈ E ; for started in state K1¤ on an empty stack reaches either each vertex u ∈ V2 , F (u) is the conjunction of all F (v) of the states K2¤ or K2¥ with the stack empty at the end. such that (u, v) ∈ E . It is well known that this fix point It is easy to see that size of δ is O(LD + |D|) and can be computed in time linear in the size of H using size of Q is O(|K| + LD ). a simple iterative approach as follows. With each vertex u, we maintain a variable label(u) which is initialized to From the normalized PDS P we construct an equiva- T rue for vertices of the form [p, p] and is initialized to lent context free grammar G according to the rules given F alse for all other vertices. We also maintain a counter in [Sip01]. The variables (i.e., non-terminals) of G are c(u) with each vertex u which is initialized to zero for {Apq |p, q, ∈ Q}. The production rules of G are described all vertices. The algorithm also maintains a set X of below. vertices. Initially, X is the set of nodes of the form [p, p]. For each p, q, r, s ∈ Q and A ∈ Γ, such that δ After this we iterate the following procedure as long as contains the transitions (p, ², r, A), (s, ², A, q) (i.e., the X is non-empty. We delete a node v from X , examine first transition pushes A onto the stack while the second all nodes u from which there is an edge to v ; if u ∈ V1 pops the same symbol from the stack) we have the rule (i.e.,is an or-node) and c(u) is zero then we increment Apq → Ars in G. c(u), set label(u) to T rue and add u to the set X ; if For each p, q, r ∈ Q we have the rule Apq → Apr Arq u ∈ V2 (i.e., is an “ and” node) and c(u) < 2 then we in G . increment c(u), further if c(u) = 2 after this increment, For each p ∈ Q, we have the rule App → ² in G . we set label(u) to T rue and add u to X . It is easily shown that at the end of the above algo- The only terminal symbol of the grammar is the null rithm, for any vertex u of the form [p, q], label(u) is string ². Let Q0 ⊂ Q be the set K∪{(i, li )| 1 ≤ i ≤ |D|}. T rue iff the contex free grammar G can generate the Due to the semantics of SPKI, it is easy to see that empty string ² from the non-terminal Apq . Using this and among the rules of type Apq → Apr Arq , the ones that the results of [Sip01], the following theorem is easily are useful are those in which q, r ∈ Q0 . It is easy to proved. see that the number of rules of this type is bounded by Theorem: At the end of the above algorithm, for any O((|K| + LD )(|K| + |D|)|D|). The total number of rules vertex u of the form [p, q], label(u) = T rue iff the PDS is O((|K| + LD )(|K||D| + |D|2 )). The CFG G has the when started in state p with empty stack reaches state q following property. The PDS P can go from state p to q with empty stack. starting and ending in a empty stack iff we can generate The size of H which is (|V | + |E|) can be shown the empty string ² from CFG symbol Apq . The term to be O((|K| + LD )(|K||D| + |D|2 )). Thus the reachability problem of the PDS has been converted to complexity of the above fix point computation is a word problem in the CFG. O((|K| + LD )(|K||D| + |D|2 )). From the above grammar G we construct a directed And-Or graph H = (V, E). The vertex set V is a Recall that, at the beginning of the section, we de- disjoint union of two sets V1 , V2 . V1 is the set of all scribed a method for computing relation Rg for each pairs of the form [p, q] where p ∈ Q and q ∈ Q0 . V2 is atomic formula g . This procedure used a sequence of the set of all triples of the form [p, q, r] where p ∈ Q sets of certificates C0 , C1 , ..., Cl−2 where l ≤ 2,. and q, r ∈ Q0 . Each vertex in V1 is an “ or” vertex while Rg is constructed by computing Evalg,i for i = 0...l− each vertex in V2 is an “ and” vertex. The set E of 2. It should be easy to see that, for any fixed i, Evalg,i for all g can be computed by constructing the And-or preserve this property. The union of two normalized lists graph corresponding to the set of certs Ci . L1 and L2 is another normalized list covering exactly the Evalg,i can be computed from the And-or graph Hi union of the time points covered by the two lists. The corresponding to the set of certificates Ci as follows. intersection of two normalized lists is a normalized list Assume g is authorize(p, q, d, e). If both p, q are that covers exactly the time points common to both of the variables and d = 1 then Evalg,i is the set of all pairs lists. The union and intersection of two normalized lists (K1 , K2 ) such that the vertex (K1¤, K2¤) is labeled T rue can be computed in time proportional to the sum of the in graph Hi . If d = 0 then we check if either the above sizes of the two lists. The complement of a normalized vertex or the vertex (K1¤, K2¥) are labeled T rue in Hi . If list L1 is a normalized list that covers exactly all time both p, q are keys say K1 , K2 and d = 1, then Evalg,i is points in the interval [0, ∞] that are not covered by the singleton set containing the empty evaluation if the L1 . The complement of a normalized list can also be vertex (K1¤, K2¤) is labeled T rue; otherwise, it is the computed in time linear in the size of the list. empty set. Other cases are similarly handled. Now we give the second part of the algorithm based Assume g is resolve(p, q). In this case p is a name on structural induction for computing relation Rg of and q can be a key or a variable. We can assume that a subformula g when g is not atomic. The algorithm p is the prefix of the right hand side of some rule j in computes relation Rg for each subformula g of f in Ci (If this is not the case then we can add a dummy rule the increasing lengths of the subformula g . On termi- whose right hand side is p). Assume that the length of nation of the algorithm we have the required relation p(number of identifiers) is k . Rf . We call the list in each tuple of the relation Rg If q is a key then Evalg,i is the singleton set containing as the validity list of the tuple. We want to show the empty evaluation if the node [(j, k), q] in Hi is that the length of the validity list in each tuple of labeled T rue; otherwise, it is the empty set. If q is a in Rg is of length O(m|g|). To show this, we first variable then Evalg,i is the set of all K1 such that the define a finite set of time points (i.e., positive inte- node [(j, k), K1 ] in Hi is labeled T rue. gers), called extreme points(g), such that the beginning In the above computation if Ci+1 ⊇ Ci , then the and ending time points of each interval in the validity graph Hi+1 is obtained by adding new edges to Hi , lists of tuples in Rg belong to extreme points(g). corresponding to additional certs in Ci+1 . The fixpoint The set extreme points(g) is defined inductively on computation on Hi+1 can start with the labels computed the structure of g . If g is an atomic proposition then for Hi and continue with the additional edges till a new extreme points(g) is the set of points {Ti , Ti + 1 : fixpoint is reached. Thus we can take advantage of the 0 ≤ i < l} as given at the beginning of this section. incremental nature of the fix point computation, with It is to be noted the cardinality of this set is O(m). respect to addition of edges to the And-or Structure. It If g = h ∧ h0 then extreme points(g) is the union of is to be noted that if Ci+1 ⊆ Ci , then Hi+1 is obtained extreme points(h) and extreme points(h0 ). If g = ¬h from Hi by deleting some edges. However we cannot then extreme points(g) is same as extreme points(h). apply incremental computation while deleting edges in If g = Xh then extreme points(g) is the set {0, t − the graph Hi , as the lest fixpoint computation is not 1 : t ∈ extreme points(h)}. If g = hU[t1 ,t2 ] h0 , incremental with respect to the deletion of edges in the then extreme points(g) is the set {t − t1 , t − t2 , t + And-or structure. 1 − t1 , t + 1 − t2 : t ∈ extreme points(h) or Since |Ci | ≤ m, from the above analysis we can see t ∈ extreme points(h0 )}. If g = ∃ i(h) then that Rg , for any atomic g , can be computed in time extreme points(g) is same as extreme points(h). By O(m(|K| + |LC |)(Km + m2 )). induction on the length of g , it can be shown that the cardinality of extreme points(g) is O(m|g|). In the In our algorithm presented below for computing Rf , construction of Rg given below, it should be easy to we need to maintain lists of intervals of time. A list of see that the begin and end points of each interval in intervals is maximal if every pair of intervals in the list the validity list of each tuple in Rg is from the set is non-overlapping and non-adjacent (two time intervals extreme points(g). Since the intervals in a validity list [s, s0 ], [t, t0 ] are non-overlapping and non-adjacent if t > are disjoint, each point in extreme points(g) can appear s0 + 1 or s > t0 + 1). We maintain all lists in such as the end point of atmost one interval. Hence, the length a way that they are maximal and the intervals are in of each such validity list is O(m|g|). sorted order. We call such lists as normalized. We define Let |Rg | denotes the number of tuples in the relation the size of such a list as the number of intervals in it. Rg corresponding to a formula g . As shown above, the All our lists are in normalized form and all operations length of any validity list of a tuple in Rg is of O(m|g|) where m is the number of certificates. Since the number Consider a subformula g = hU[t1 ,t2 ] h0 , where Rh , Rh0 of free variables appearing in g is at most |g|, we see are the relations computed for formulas h and h0 , having that the size of any single tuple including its validity list (i + 1) and (j + 1) attributes respectively. If h, h0 have v is O(|g| + m|g|) which is O(m|g|). Hence, the size of number of common variables, then Rg has (i+j −v +1) Rg is O(m|Rg ||g|). attributes. For a given instantiation ρ of values if h is If the subformula g is of the type ¬h, then for every satisfied during the times given by validity list L1 , h0 is tuple of form (K1 , K2 , ..., Kr , L) ∈ Rh we include the satisfied during the time intervals given by the validity tuple (K1 , K2 , ..., Kn , L) in Rg . L is the complement of list L2 , we give a method to calculate L12 the list of the validity list L as defined earlier. As shown previously time intervals during which g is satisfied. We define two we can compute L in time linear in the size of the list intervals [p1 , p2 ] ∈ L1 , [q1 , q2 ] ∈ L2 as compatible if L. Hence we can compute Rg in time O(m|Rh ||h|). they overlap or if [p1 , p2 ], [q1 , q2 ]are adjacent i.e. q1 = Consider a subformula g = h ∧ h0 , where Rh , Rh0 are p2 + 1. To compute L12 take two compatible intervals the relations computed for formulas h and h0 , having I1 = [p1 , p2 ] ∈ L1 , I2 = [q1 , q2 ] ∈ L2 , then by the (i + 1) and (j + 1) attributes respectively. If h, h0 have v definition of the bounded until operator we can show number of common variables, then Rg has (i+j −v +1) that the corresponding interval I12 ∈ L12 during which attributes. For a given instantiation ρ if h is satisfied the formula g holds good is [max(T − t2 , p1 ), max(T − during an interval I (in the validity list) and h0 during I 0 , t1 , p1 )] where T = min(p2 + 1, q2 ). Thus we compute g is satisfied during time I ∩ I 0 . For a tuple t1 in Rh and all the intervals in L12 from the compatible intervals a tuple t2 in Rh0 , we include a tuple t12 in Rg , if the cor- of L1 and L2 . Given that we maintain the validity lists responding values of of the common variables in the two in a normalized condition we can calculate L12 in time tuples are equal and the intersection of the corresponding linear in the sum of sizes of validity lists L1 and L2 . validity lists is not empty. We include in the tuple t12 For a tuple t1 in Rh and a tuple t2 in Rh0 , we include all the values related to the variables(without repeating a tuple t12 in Rg , if the values of tuples corresponding the common variable values) and the validity list in the to the common variables are equal and the composition tuple t12 is given by intersection of the validity lists in of corresponding validity lists as defined above is not t1 and t2 . Given that we can compute the intersection of empty. We include in the tuple t12 all the values related two validity lists in time linear in the sum of their sizes, to the variables(without repeating the common variable we can compute Rg in time O(m|Rh ||Rh0 |(|h| + |h0 |)). values) and the validity list in the tuple t12 is given If the subformula is of the type g = Xh, then for by composition of corresponding validity lists in t1 every tuple in Rh of the form (K1 , ...Kr , L), we include and t2 as defined above. We can compute Rg in time the tuple (K1 , ...Kr , L0 ) in Rg where L0 is as defined O(|Rh ||Rh0 |m(|h| + |h0 |)). below; L0 consists of all intervals of the form [max(ti − Thus we calculate the relation Rf for the formula f 1, 0), tj − 1] such that [ti , tj ] ∈ L. We can compute L0 inductively from the components of the formula. Let n in time linear in the size of L. Hence we can compute be the total number of principals in the system, L the Rg in time O(m|Rh ||h|). sum of lengths of right hand side of all certificates and If the subformula is g = ∃ih(i), then Rg is computed k the number of variables in the formula f . For any as follows. Let r + 1 be the number of attributes of the formula g(i1 , ..., ili ) with li number of variables the size relation Rh . With out loss of generality, assume that the of relation Rg is of order O(nli m|g|) because each of the j th attribute of Rh gives the value of the variable i. Note variables can be any of the n principals in the system. that the values of the last attribute is the validity list of The normalized validity list of a tuple in Rg can be main- the tuple. We group the tuples of Rh into the smallest tained in the size of O(m|g|). The relation Rg obtained collection of groups G1 , .., Gl such that each group Gp by composition of relations Rh and Rh0 can be computed satisfies the following property: all the tuples in Gp have in time O(|Rh ||Rh0 |m(|h| + |h0 |)). If h contains li vari- the same values for the q th attribute, for each q such ables and h0 contains lj variables, Rg can be computed that q 6= j and 1 ≤ q ≤ r. Corresponding to each group in time O(nli nlj m(|h| + |h0 |)) = O(nli +lj m(|h| + |h0 |)). Gp , Rg has a single tuple (K1 , .., Kj−1 , Kj+1 , ..., Kr , L) Thus the overall formula can be computed in time where Kq , for 1 ≤ q ≤ r and q 6= j , is the value of the O(nli +lj +... m(|h| + |h0 | + ...)) = O(nk m|f |). Since the q th attribute in a tuple in Gp and L is the union of all size of formula |f | ≈ k the complexity of evaluating the the validity lists in the tuples in Gp ; it is to be noted that formula f given the relations for the atomic formulas the list L can be computed in time linear in the sum of authorize and resolve is O(n|f | m|f |). The overall the sizes of the validity lists in the tuples of Gp . Hence complexity of evaluating the formulas of the logic FTPL we can calculate Rg in time O(m|Rh ||h|). is O(n|f | m|f |) + O(m(n + L)(nm + m2 )). VI. C ONCLUSION AND F UTURE W ORK [JR01] Somesh Jha and Thomas Reps. Analysis of spki/sdsi certificates using model checking. In 15th IEEE Com- In this paper, we have proposed a language for ana- puter Security Foundations Workshop, pages 129–144, lyzing a set of policy statements labeled with validity Cape Breton, Canada, 24–26 June 2001. IEEE Computer intervals and gave a list of problems that could be Society Press. [JR02] S. Jha and T. Reps. Analysis of spki/sdsi certificates specifiable by the language. We also gave algorithms using model checking. In Computer Security Foundations for computing the formulas of the logic in a incremental Workshop (CSFW), June 2002. fashion. In future we propose to modify the semantics of [Li00] Ninghui Li. Local names in SPKI/SDSI. In Proceed- ings of the 13th IEEE Computer Security Foundations the modal operators of FTPL to consider a state transition Workshop, pages 2–15. IEEE Computer Society Press, model for the SPKI access control system. jul 2000. [LM03] Ninghui Li and John C. Mitchell. Datalog with con- straints: A foundation for trust management languages. R EFERENCES In Proceedings of the Fifth International Symposium on Practical Aspects of Declarative Languages, January [Aba97] Martin Abadi. On SDSI’s linked local name spaces. 2003. To appear. In PCSFW: Proceedings of The 10th Computer Security [LWM01] Li, Winsborough, and Mitchell. Distributed credential Foundations Workshop. IEEE Computer Society Press, chain discovery in trust management. In SIGSAC: 8th 1997. ACM Conference on Computer and Communications Se- [ADT02] A. Arsenault, Diversinet, and S. Turner. Internet X.509 curity. ACM SIGSAC, 2001. Public Key Infrastructure: Roadmap. PKIX working [LWM03] Ninghui Li, William H. Winsborough, and Mitchell group-Internet Draft, 2002. Mitchell. Beyond Proof-of-Compliance: Safety and avail- [BEO97] A. Bouajjani, J. Esparza, and O.Maler. Reachability ability analysis in trust management. In Proceedings analysis of pushdown automata: application to model- of the 2003 Symposium on Security and Privacy, pages checking. Lecture Notes in Computer Science, 1243, 123–139, Los Alamitos, CA, May 11–14 2003. IEEE 1997. Computer Society. [BFIK99] Matt Blaze, Joan Feigenbaum, John Ioannidis, and An- [San98] R. S. Sandhu. Role-based access control. In gelos D. Keromytis. The role of trust management in M. Zerkowitz, editor, Advances in Computers, volume 48. distributed systems security. pages 185–210, 1999. Academic Press, 1998. [BFK99] Matt Blaze, Joan Feigenbaum, and Keromytis Keromytis. [Sip01] Michael Sipser. Introduction to the Theory of Computa- KeyNote: Trust management for public-key infrastruc- tion. PWS Publishing Company, 20 Park Plaza, Boston, tures. In Bruce Christianson, Bruno Crispo, William S. MA 02116, 2001. Harbison, and Michael Roe, editors, Security Protocols— 6th International Workshop, volume 1550 of Lecture Notes in Computer Science, pages 59–66, Cambridge, United Kingdom, 1999. Springer-Verlag, Berlin Ger- many. [CEE+ 01] Dwaine Clarke, Jean-Emile Elien, Carl Ellison, Matt Fre- dette, Alexander Morcos, and Ronald Rivest. Certificate chain discovery in SPKI/SDSI. Journal of Computer Security, 9(4), 2001. [EFL+ 99] Carl M. Ellison, Bill Frantz, Butler Lampson, Ron Rivest, Brian Thomas, and Tatu Ylonen. RFC 2693: SPKI Certificate Theory. The Internet Society, September 1999. See ftp://ftp.isi.edu/in-notes/rfc2693.txt. [EHRS00] Esparza, Hansel, Rossmanith, and Schwoon. Efficient algorithms for model checking pushdown systems. In CAV: International Conference on Computer Aided Veri- fication, 2000. [Ell99] Carl M. Ellison. RFC 2692: SPKI requirements. The Internet Society, September 1999. See ftp://ftp.isi.edu/in-notes/rfc2692.txt. [HK00] Jon Howell and David Kotz. A formal semantics for SPKI. In Proceedings of the Sixth European Symposium on Research in Computer Security (ESORICS 2000), volume 1895 of Lecture Notes in Computer Science, pages 140–158. Springer-Verlag, October 2000. [HRU75] Michael A. Harrison, Walter L. Ruzzo, and Jeffrey D. Ullman. On protection in operating systems. In Proceed- ings of the fifth ACM symposium on Operating systems principles, pages 14–24. ACM Press, 1975. [HvdM01] Joseph Y. Halpern and Ron van der Meyden. A logic for sdsi’s linked local name spaces. Journal of Computer Security, 9:105–142, 2001. Language Based Policy Analysis in a SPKI Trust Management System Arun K. Eamani A. Prasad Sistla Univ. of Illinois at Chicago SPKI/SDSI(Simple Public Key Infrastructure/Simple distributed Security Infrastructure) • a mechanism for specification of policy in a distributed access control system • Proposed in [EFL+99][EU99] • Can be viewed as a trust management system Our Work • a language for specification of properties/queries of a policy • an algorithm for checking satisfaction of a policy given in the language Outline of the talk • SPKI system and policy analysis • Related work • Language description • Algorithms • Conclusion SPKI/SDSI System • Policy specified through certificates or credentials(in short, certs) • Two types of certs: – authorization certs: • Used by administrators to authorize principals to access resources. – name certs: • used to define groups of users Naming scheme • Principals, resources are identified by their public keys • Ex: Kuic : public key for UIC Kuiuc : public key for UIUC • I: a set of identifiers e.g. {friends, brothers} • Local name(space): a key followed by an identifier – Defines a set of principals – E.g.: Kjohn friends, Kjohn brothers Name scheme cont’d • Extended names: a key followed by two or more identifiers – Kbob friends brothers • name: local name or extended name • Term: name or key – Also called fully qualified name Certificates • name certs: define a local name – Structure: (K, A, S, V) • K: key • A: identifier • S: fully quantified name • V: validity time interval – Written as rule: K A  S – Defines that every member of S is a member of K A. Example KBob friend K John KJohnbrother K David KBob friend K Joe friend brother Authorization certs (K, S, D, E, V) • K: public key • S: subject — a fully qualified name • D: delegation bit – 1: has delegation right – 0: no delegation right • E: set of authorization rights • V: validity time interval • Written as: K   S  when D=1 • K   S  when D=0 Example • R   KBob  • KBob   K John friend  • K John friend  K Joe • K John friend  K David • K Joe ,K David can access the resource without delegation rights. Rewriting Rules/Tuple Reduction • Each name cert/auth cert is considered as a rewriting rule • term T1 can be transferred to T2 using the rewriting rules. Example KBob friend K John KJohn brother K David • “KBob friend brother” resolves to “K David ” means K David is a member of the group “KBob friend brother” • K John can access the resource R if R  resolves to K John  or K John  Policy Analysis • answering queries and questions about a given policy • Can principal K Joe access the resource R? • Is principal K Joe a member of “KBob friend brother” ? Related Work • [JR02]: Jha and Reps use model checking for policy analysis • [Aba97]: use logic to model local name space • [HvdM01]: use logic for semantics • Clarke et al: use certificates chains for proof of compliance Related Work(Cont’d) • Most policy analysis done for fixed set of properties • We propose a general purpose language for specifying properties • We give algorithm for checking any propertie specified in the language. Language Description • FTPL(First order Temporal Policy Language) • A policy state: a set of certificates valid at a given time Due to valid intervals, policy state changes over time Suppose the policy has two certs : C1 valid [0 10] C2 valid [5 15]. Defines a sequence of policy states: {C1}, {C1,C2}, {C2}. The first state lasts from 0 to 5 time units, the second from 6 to 10, and the last from 11 to 15 . FTLP feature • FTPL has constraints to reason about a single policy state as well as a sequence of policy states • Uses variables and first order quantifiers ranging over principals. i, i • Uses temporal operators to specify temporal properties FTPL con’t • Employs two predicates: – Resolve( p, q ): denotes p resolves to q • p can be a term • q can be a term or a variable – Authorize( p, q, d, e): denotes “p authorize q to have the right specified by e” • p is a variable or a key • q is a variable or a name FTPL cont’d • Quantifiers:  i: for all principals i  i: for some principal i • Temporal Operators:  [10,20] : eventually with in time 10 to 20 units from now   [10,20] : at all times between 10 to 20 time unites from now  : next time • Logic connectives: (and), (or), (not),  (implication) Examples • authorize(R, KB, 0, {read}) – KB has a “read” access right without delegation at the beginning  [0, t] authorize(R, KB, 0, {read}) – KB has a “read” access right some time before t  [0, t] authorize(R, KB, 0, {read}) – KB has a “read” access right at all times before t  [0, ] ( authorize(R, K1, 0, {write})  authorize(R, K2, 0, {write}) ) – K1’ K2 both have write access right at the same time some time in future Using quantifiers  i ( resolve(KBob friend, i )  authorize( R, i, 0, {write}) ) – Some friend of Bob has a write access  i ( (resolve(KBob friend, i )  authorize( R, i, 0, {write}) ) – Every friend of Bob has a write access   authorize( R, K2 , 0, {r}) Until[0, ] authorize(R, K1 , 0, {r}) – K1 has access right r before K2 Example con’t • Violation of separation of duty:  [0, ] i ( resolve(R1 , i)  resolve (R2 , i)) Roles R1, R2 have a common member at some point in time • Violation of Containment:  [0, ] i ( authorize( P, i, 0, {r})   resolve(R,i) ) There is a principal not a member of R and has “r” access right at some time Queries • authorize( R, i, 0, {r}) – Retrieves all principals having “r” access at the beginning  [0, t] authorize( R, i, 0, {r}) – Retrieves all principals having “r” access at all times up to t Evaluation of the formulas • Given a certificate system C, and a formula f with k free variables, we compute a relation Rf that has k+1 attributes: – In each tuple of Rf , the first k attributes give the values of the free variables and the last attribute gives a set of time intervals when f is satisfied – If f has no free variables, then Rf retrieves a set of time intervals during which f is satisfied – E.g.: f = authorize(R, i, 0, {r}) Rf : KBob , {[10,20], [30,40]} Kjohn , {[5,10]} Outline of the algorithm • Compute the subformulas of f as set F • For each member g in F, in increasing length of g If g is an atomic subformula, compute Rg using an “and- or’’ graph; // the “and-or” graph captures the proofs of compliance in a finite structure; a single fix point computation computes all such Rg else compute Rg using the relations {Rh where h is an immediate subformula of g} Complexity O( m2 (n+m)(n+L) + m|f|2 nu(f) ) – m:  of certs – n:  of keys – L: sum of the length of right hand sides of the certs – |f|: length of the formula – u(f):  of variables in f Conclusion and future work • Our method can be used for policy analysis and policy audit • Implementation ? Enhancing Security of Security-Mediated PKI by One-time ID Satoshi Koga1 , Kenji Imamoto1 , and Kouichi Sakurai2 1 Graduate School of Information Science and Electrical Engineering, Kyushu University 6-10-1 Hakozaki, Higashi-ku, Fukuoka, 812-8581, Japan {satoshi,imamoto}@itslab.csce.kyushu-u.ac.jp 2 Faculty of Information Science and Electrical Engineering, Kyushu University 6-10-1 Hakozaki, Higashi-ku, Fukuoka City, 812-8581, Japan sakurai@csce.kyushu-u.ac.jp Abstract. The Security Mediator (SEM) approach was proposed by Boneh et al. at USENIX Security Symposium in 2001. However, their Security-Mediated PKI has a drawback that it is vulnerable to Denial- of-Service (DoS) attacks, since an attacker can send a lot of requests to the SEM server. To prevent DoS attacks, some solutions are proposed. In this paper, we show that the use of Message Authentication Code (MAC), which is one of the solution proposed, cannot avoid DoS attacks because an attacker can reuse the request for replay attacks. In order to prevent DoS attacks efficiently, this paper proposes Security-Mediated PKI using one-time ID. Our proposed system can avoid DoS attacks and protect the privacy of signers, since one-time ID can be used only once. Keywords: Public Key Infrastructure, Certificate Revocation, Security Media- tor, One-time ID 1 Introduction 1.1 Background A Public Key Infrastructure (PKI) is the basis of security infrastructure whose services are implemented and provided using public key techniques. Most of the protocols for secure e-mail, web service, virtual private networks, and au- thentication systems make use of the PKI. In the PKI, a certificate is used to bind an entity’s identity information with the corresponding public key. When a certificate is issued, its validity is limited by a pre-defined expiration time. Nevertheless, certificates are revoked in case of breaking that binding before its expiration date. Thus, the certificate verifier must check not only the expiration date on the certificate but also the revocation information of it. A certificate revocation system can be implemented in several ways. The most well-known method is to periodically publish a Certificate Revocation List (CRL) [6, 8], which is a digitally signed list of revoked certificates and usually issued by the Certification Authority (CA). One of the shortcomings of CRL systems is that the time granularity of revocation is constrained by CRL issuance periods. It is necessary to obtain timely information regarding the revocation status of a certificate. The most popular mechanism that provides real-time status of a certificate is the Online Certificate Status Protocol (OCSP) [13]. The OCSP provides the up-to-date response to certificate status queries. Since the user just requests to return the status of certificate, the communication costs can be reduced in comparison to the CRL. Recently, Boneh et al. observed that existing revocation techniques, including OCSP, don’t provide immediate revocation [3]. Supporting immediate revoca- tion with existing revocation techniques would result in heavy performance cost and very poor scalability. To provide immediate revocation, SEcurity Mediator (SEM) approach was proposed [2, 3]. The basic idea of SEM is as follows. They introduce a new entity, referred to as a SEM: an online semi-trusted server. To sign or decrypt a message, a client must first obtain a message-specific token from its SEM. Without this token, the user cannot accomplish the intended task. To revoke the user’s ability to sign or decrypt, the security administra- tor instructs the SEM to stop issuing tokens for that user’s future request. The SEM approach provides several advantages. This approach can eliminate the need for CRLs since private-key operations cannot occur after revocation. That is, this approach enables immediate revocation. Recently, Vanrenen et al. pro- posed a distributed SEM architecture [14], and Bicakci et al. proposed Privilege Management Infrastructure based on SEM approach [1]. 1.2 Motivation As Boneh et al. pointed out in [3], one of the drawbacks of SEM approach is that it is vulnerable to Denial-of-Service (DoS) attacks. The SEM server must generate the token for every user’s request. That is, for every simple request sent by an attacker, the SEM server must generate the token, which is a computa- tionally intensive operation. Consequently, it becomes highly vulnerable to DoS attacks. The goal of this paper is to prevent DoS attacks. 1.3 Related Work To prevent DoS attacks, there are some solutions as follows [3]. 1. Digital signatures The simple solution is to authenticate the user by verifying digital signature [3]. For example, a user can generate a partial signature on each request message as follows. (See Section 2.3 for notations.) hEC(m), EC(m)du mod ni The SEM computes a digital signature S(m) = (P Ssem ∗ P Su ) mod n and verifies it by using public key. Although this method does not prevent DoS attacks, since a SEM would need to perform two modular exponentiations to authenticate each request [3]. 2. Secure Sockets Layer (SSL) Another solution is to rely on more general encapsulation techniques, such as SSL, to provide a secure channel for communications between SEMs and users [3]. However, the user must validate the SEM’s certificate in order to establish secure channel. Therefore, the burden of a user becomes heavy since the certificate validation processing is intensive operations. 3. Message Authentication Code (MAC) More cost-effective approach is to use MAC or keyed hash [3]. This situa- tion requires a shared secret key between a SEM and each user. This paper shows that this approach cannot prevent DoS attacks. An attacker can reuse requests generated by legal users, and send a lot of requests to a SEM. Even if the SEM authenticates requests by checking MAC, it is vulnerable to DoS attacks based on replay attacks, as discussed in Section 3. 4. The DoS resistant protocol To avoid DoS attacks from any malicious stranger, it is important to make him have a large burden in sending a lot of requests. One approach to solve the DoS problem is to make the client compute some form of proof of compu- tational effort [5, 12]. This approach is effective to DoS attacks, however com- putational costs of the legal user are also increasing as well as DoS attackers. In our proposed method, only attackers require exhaustive computations. 1.4 Our Contributions This paper shows that traditional solutions cannot prevent DoS attacks. An attacker can reuse requests generated by legal users, and send a lot of requests to a SEM. Even if the SEM authenticates requests by checking MAC, it is vulnerable to DoS attacks based on replay attacks. It is necessary to avoid DoS attacks based on replay attacks efficiently. This paper proposes the SEM approach using One-time ID. One-time ID is a user’s extraordinary identity, which has two properties as follows: (1) an attacker can- not specify who is communicating even when she eavesdrops on one-time ID, and (2) One-time ID can be used only once. Our proposed method requires a shared secret key between a SEM and each user. A user sends a request containing a message and one-time ID. One-time ID can be derived by shared secret key and be used only once. By checking one-time ID, a SEM server can confirm that requesting user is legal user. In our proposed method, the user sends a request containing Message Authentication Code (MAC). Therefore, an attacker cannot create the legal request. Moreover, an attacker cannot reuse requests for replay attacks because the One-time ID is used only once. Our proposed system has the following benefits. 1. DoS-resilient A SEM can efficiently detect illegal requests, since an attacker cannot gen- erate one-time ID unless she obtains a shared secret key. Moreover, our proposed system can prevent replay attacks. An attacker cannot reuse the request generated by legal user because one-time ID can be used only once. 2. Efficiency One-time ID can be generated by hash computations. Therefore, computa- tional costs of a SEM and a user are more efficient, compared with signature- based solutions. Additionally, communications between a SEM and a user are the same as the existing Security-Mediated PKI. 3. Privacy In existing approaches, a user must send a request contained a public key certificate. Thus, an attacker can trace the user’s identity by tracking user’s request. It is easy to know the user’s private information (e.g. user’s name, affiliation, address and so on.) from the serial number of his certificate. In our proposed system, an attacker cannot trace user’s identity even if she eavesdrops on one-time ID, because one-time ID dynamically changes. That is, our proposed system can protect the privacy of signers, compared with existing approaches. The rest of this paper is organized as follows. In Section 2, we explain the SEM approach. In Section 3, we show that the traditional approach cannot prevent DoS attacks. In Section 4, we describe our proposed system and Section 5 discusses as to security of our proposed system. Concluding remarks are made in Section 6. 2 Security-Mediated PKI 2.1 Model In a Security-Mediated PKI, there are three entities, as shown in Fig.1. 1. Certification Authority (CA) A Certification Authority (CA) is a trusted third party that issues certifi- cates. Compromise of CA’s private key will affect the entire system, so the CA is isolated from the Internet to prevent unauthorized accesses. 2. SEM (SEcurity Mediator) A SEM is an online semi-trusted server. A single SEM serves many users. 3. User Users trust the CA and SEM. To sign or decrypt a message, they must first obtain a message-specific token from its SEM. 2.2 An overview of a SEM The basic idea of SEM approach is as follows [2]. We introduce a new entity, referred to as a SEM. A SEM is an online trusted server. To sign or decrypt a message, Alice must first obtain a message-specific token from the SEM. Without this token Alice cannot use her private key. To revoke Alice’s ability to sign or decrypt, the security administrator instructs the SEM server to stop issuing @BA .C%&)7D=& )FEG,   ! "# $%&'  (  ! "*)+ ,&! ( %    - &.%) "   (&/  ' "0+ (1 2' ( % 3 &4 (165 %7.98:;2"   < '=>&? "   Fig. 1. A general SEM algorithm tokens for Alice’s public key. At that instant, Alice’s signature capabilities are revoked. Fig. 1 shows the general SEM algorithm. A SEM approach is to enable immediate revocation of user’s key. This method provides two additional benefits over standard revocation techniques: (1) sim- plified signature validation, and (2) enabling revocation in legacy systems. The SEM approach naturally provides the following semantics for digital signatures: Binding Signature Semantics: a digital signature is considered valid if the public key certificate associated with the corresponding private key used to gen- erate the signature was valid at the time the signature was issued. 2.3 Mediated RSA This section describes in detail how a SEM interacts with users to generate tokens. The SEM architecture is based on a variant of RSA called Mediated RSA (mRSA). The main idea is to split each RSA private key into two parts using simple 2-out-of-2 threshold RSA [4]. Each user U has a unique public key and private key. The public key P K includes n and e, where the former is a product of two large distinct primes (p, q) and e is an integer relatively prime to φ(n) = (p − 1)(q − 1). There is also a corresponding RSA private key SK = (n, d) where d ∗ e = 1 mod φ(n). However, as mentioned above, no one party has possession of d. Instead, d is effectively split into tow parts: du and dsem which are secretly held by the user and the SEM, respectively. The relationship among them is: d = dsem + du mod φ(n) The CA generates a distinct set: {p, q, e, d, dsem , du } for the user. The first four values are generated as in standard RSA. The fifth value, dsem , is a random integer in the interval [1, n], where n = pq. The last value is set as: du = d − dsem mod φ(n). The protocol of key generation algorithm is as follows. Let k be a security parameter. After CA computes, dsem is securely communicated to the SEM and SK is communicated to the user. (Algorithm: key generation) (1) Generate random k/2-bit primes: p, q (2) n ← pq r ∗ (3) e ←− Zφ(n) (4) d ← 1/e mod φ(n) r (5) dsem ←− 1, ..., n − 1 (6) du ← (d − dsem ) mod φ(n) (7) SK ← (n, du ) (8) P K ← (n, e) 2.4 mRSA signatures According to PKCS #1v2.1 [11], RSA signature generation is composed of two steps: message encoding and cryptographic primitive computation. We denote by EC() the encoding function. This encoding includes hashing the input message m using a collision resistant hash function. EC() is the EMSA-PKCS1-v1 5 encoding function, recommended in [11]. 1. The user sends the message m to the SEM. 2. The SEM checks the user’s certificate. Only if this certificate is valid, the SEM computes a partial signature P Ssem = EC(m)dsem mod n, and replies with it to the user. 3. The user computes P Su = EC(m)du mod n. Then, the user receives P Ssem and computes S(m) = (P Ssem ∗ P Su ) mod n. It then verifies S(m) as a standard RSA signature. If the signature is valid, the user outputs it. 3 Disadvantages of a SEM approach One of the drawbacks of SEM approach is that it is vulnerable to Denial-of- Service (DoS) attacks, as pointed in [3]. There are three types of DoS attack: against SEM’s bandwidth, memory, and CPU. The purpose of the first attack is that a SEM cannot receive any more messages. The second one is performed to make a SEM store large quantities of waste states. The last one is the attack which makes a SEM computes a lot of quite inefficient processings. In SEM approach, we focus on DoS attacks against SEM’s CPU. The SEM server must generate the partial signature for every user’s request. If an attacker can send a lot of requests, the SEM must compute a lot of partial signatures. Computations of a partial signature require a modular exponentia- tion. Consequently, it becomes highly vulnerable to DoS attacks. To prevent DoS attacks, the SEM authenticates incoming requests. Only if a legal user sends a request, the SEM computes a partial signature. The SEM does not respond any request, sent by a party whom the responder cannot specify. Additionally, the SEM should confirm that the request is fresh. If an attacker can eavesdrop on communications between a legal user and a SEM, she can reuse a request created by legal users for replay attacks. That is, an attacker can send a lot of legitimate requests to the SEM. To prevent DoS attacks based on replay attacks, the SEM only responds to new requests. In [3], several solutions are proposed. However, these solutions cannot prevent DoS attacks efficiently. Most cost-effective approach is to use Message Authenti- cation Code (MAC) or keyed hash [3]. This situation requires a shared secret key k between a SEM and each user. A SEM can authenticate the request by checking MAC. However, it is vulnerable to replay attacks. An attacker can reuse requests generated by legal users, and send a lot of requests to a SEM. Suppose that the le- gal user sends requests hM ACk (m1 ), m1 i, hM ACk (m2 ), m2 i, ..., hmn , M ACk (mn )i, as shown in Fig. 2. M ACk (mi ) denotes the MAC using shared key k as the in- put message mi . An attacker can eavesdrop these requests and send them to the SEM. This attack is called as replay attack. The SEM misunderstands that these request sent by an attacker are legal requests, and computes partial signatures, since the SEM cannot detect replay attacks. 4 Our proposed method In MAC approach proposed in [3], the SEM cannot detect replay attacks. Sup- pose that an attacker, who doesn’t know secret value, can eavesdrop and modify the data between the SEM server and the legal user. Under this environment, the goal of this paper is to prevent DoS attacks efficiently, and to protect the privacy of signers. This paper proposes Security-Mediated PKI using one-time ID. 4.1 One-time ID To prevent leakage of user’s identity and DoS attacks, Krawczyk proposed “One- time ID” [9]. One-time ID is a user’s extraordinary identity, which has two properties as follows: (1) an attacker cannot specify who is communicating even when she eavesdrops on one-time ID, and (2) One-time ID can be used only ! #"$!#" %&(')!' * +,.-0/ 1&2 354630798 +.: ;<+=/ 4 /     Fig. 2. DoS attack based on replay attack once. To realize perfect forward secrecy, Imamoto et al. proposed new method of One-time ID calculation [7]. Taking into account the computational cost of users and a SEM, we utilize one-time ID protocol with small computational complexity, like a P-SIGMA. When one-time ID is generated, this method does not require modular expo- nentiations. The user and a SEM can compute one-time ID using one-way hash function. The SEM can authenticate incoming request by checking one-time ID. Additionally, the SEM can confirm that sending request is fresh because one-time ID is used only once. Proposed system requires a shared secret key between a SEM and each user. The key-pair of a user is generated by CA, as well as the traditional SEM ap- proach. And the CA generates a shared secret key between a SEM and a user, and sends it to both a SEM and user securely. We describe the protocol of our system as follows. A user sends a request containing a message and one-time ID. One-time ID can be derived by shared secret key and be used only once. By checking one-time ID, a SEM server can confirm that requesting user is legal user. Only if requesting user is legal, a SEM generates a partial signature. Our method has the following benefits. 1. DoS-resilient A SEM can efficiently detect the attacker’s request, since an attacker can- not generate one-time ID unless she obtains a shared secret key. Moreover, proposed system can prevent replay attacks. An attacker cannot reuse the request generated by legal user because one-time ID can be used only once. 2. Efficiency One-time ID can be generated by hash computations. Therefore, computa- tion costs of a SEM and a user are more efficient, compared with traditional methods. Additionally, communications between a SEM and a user are the same as the existing Security-Mediated PKI. 3. Privacy In existing approaches, a user must send a request contained a public key certificate. Thus, an attacker can trace the user’s identity (e.g. public key certificate) by tracking user’s request. In our proposed system, an attacker cannot trace user’s identity even if she eavesdrops on one-time ID, because one-time ID is used only once. That is, our proposed system can protect the privacy of signers, compared with existing approaches. 4.2 Preliminaries (Notations) – U : user. – P K: a public key of U . – SK: a partial private key of U . – dsem : a partial private key of a SEM. – k: a shared secret key between U and a SEM. – M ACk (): Message Authentication Codes using shared key k, such as HMAC [10]. – H(): collision-resistant hash function. – OIDi : U ’s one-time ID with i-th session. – m: message. (Assumptions) 1. There is a shared secret key between the user and the SEM. 2. The secure channels are established between the CA and users, the CA and the SEM. This is the same assumption as the existing SEM approach [2, 3]. 3. Communication between the SEM and users does not have to be protected. An attacker can eavesdrop and modify the contents of request message and response message. 4.3 SEM using one-time ID (Setup) 1. As shown in Section 2.3, the CA generates P K, SK, dsem , respectively. Then the CA generates k and issues the public key certificate of U . hk, dsem i are securely communicated to the SEM and hk, SKi is communicated to U .   !"#       $&%('*)+-,/.0%'*)1  2&%'*)1-,/.0%'*)1  Fig. 3. Our proposed method 2. At first session, a SEM generates the list of OID1 and U ’s certificate. OID1 is derived as follow. OID1 = H(1, k) (Signature) 1. U makes a request using one-time ID. First, U generates OID1 and sends the following request. hM ACk (m, OID1 ), m, OID1 i 2. First, the SEM confirms that the contents of a request is fresh by using k. That is, the SEM check the MAC value M ACk (m, OID1 ). Then, the SEM checks who U is by using OID1 . If U is a legal user, the SEM validates U ’s certificate. 3. If U ’s certificate is valid, the SEM generates a partial signature P Ssem = EC(m)dsem mod n and sends the following response. Let IDsem denote SEM’s ID. hM ACk (IDsen , P SSEM , OID1 ), IDsem , P Ssem , OID1 i 4. U computes P Su = EC(m)du mod n. Then U receives above response and confirms that contents of a response is fresh by checking M ACk (P SSEM , OID1 ). m And U computes S(m) = P Ssem ∗ P Su mod n. It then verifies S(m) as a standard RSA signature. If the signature is valid, outputs it. (Update of one-time ID) 1. SEM’s update In session i, the SEM stores two one-time IDs hOIDi−1 , OIDi i for U . If one-time ID sent by U is correct, the SEM computes the partial signature and updates one-time ID as follows. OIDi+1 = H(k, OIDi ) And the SEM OIDi−1 is deleted. If connection error is occurred, U does not receive the response. In that case, U does not update one-time ID. So, the SEM stores OIDi for authenticating U . 2. U ’s update If S(m) is valid signature, U updates one-time ID as follows. OIDi+1 = H(k, OIDi ) If some error is occurred, U sends the same request once again. The SEM sends the same response. It is notice that the SEM doesn’t have to compute a partial signature again. The SEM only stores the same response. 5 Discussions 1. Signature forgery As mentioned in [2, 3], the user cannot generate signatures after being re- voked. And the SEM cannot generate signatures on behalf of the user. However, an attacker can collude with the malicious user. If an attacker compromises a SEM and learns dsem , he can create a signature by colluding with user. The existing SEM approach has the same problem. 2. DoS attacks After authenticating requests, a SEM validates a user’s certificate and gener- ates a partial signature. Suppose that an attacker can send a lot of requests to a SEM. An attacker cannot generate a legal request unless he can obtain a k. Our proposed system can prevent DoS attacks, since the SEM can detect illegal requests. 3. Replay attacks An attacker can reuse requests generated by legal users. Since one-time ID is changed for each session, an attacker cannot reuse a request for replay attacks. 4. Man-in-the-middle attack An attacker can modify the contents of request message. Suppose that U sends hOIDi , mi. An attacker modifies hOIDi , m0 i(m 6= m0 ). To prevent this attack, U sends hM ACk (m, OIDi ), m, OIDi i. Unless an attacker obtains k, an attacker cannot generate the legal request. Thus, our proposed system can prevent man-in-the-middle attacks. 5. Privacy In existing approaches, a user must send a request contained a public key certificate. Thus, an attacker can trace the user’s identity (e.g. public key certificate) by tracking user’s request. Even if the contents of the request are encrypted with k, an attacker can trace the user’s identity. This fact will be leading the privacy concerns. The privacy of signer can be protected by using SSL, but the burden of both users and the SEM may be heavy to establish the secure channel. In our proposed system, the user doesn’t have to send a request containing user’s certificate, since the SEM can specify the user by checking one-time ID. Additionally, an attacker cannot trace user’s identity even if she eavesdrops on one-time ID, because one-time ID is used only once. That is, our proposed system can protect the privacy of signers from any eavesdropper, compared with existing approaches. 5.1 Analysis of SEM’s computational costs In this section, we analyze the computational costs of the SEM. NDoS denotes the number of illegal requests sent by an attacker. Nu denotes the number of legal requests sent by legal users. P and H mean the modular exponentiation and hash computation, respectively. In the traditional SEM approach [2], the computational cost of the SEM is P (NDoS + Nu ). On the other hand, in our proposed system, the computational cost of the SEM is H(NDoS + Nu ) + P Nu . We evaluate the number of hash computations. It is assumed that P = 1000H, since H is at least 1,000 times faster to compute than P . In the tra- ditional SEM, the number of hash computations is 1000NDoS + 1000Nu . In our proposed SEM, the number of hash computations is NDoS + 1001Nu . In our proposed system, the computational costs of the SEM are more efficient than those of traditional SEM. 5.2 Other solutions There are some solutions to avoid DoS attacks based on replay attacks. This pa- per describes these methods in detail. However, these approaches cannot protect the privacy of signer. (Challenge and response) First, U sends a request message req and identifier of the user IDu to the SEM. Then the SEM responds a random number referred to as a N once. After receiving a N once, U generates a MAC using shared key k and the N once sent by the SEM. 1. U → SEM : req, IDu 2. SEM → U : N once 3. U → SEM : M ACk (m, N once), m, N once 4. SEM → U : M ACk (P Ssem , N once), P Ssem , N once – Security The SEM can confirm that the request is fresh by checking N once. The SEM must store the N once. It is possible to DoS attack against SEM’s memory. – Efficiency The number of rounds is four. It is inefficient of communications, compared with those of traditional method. (Timestamp) U generates a MAC using timestamp. T S1 denotes the time of generating a request. The SEM check that T S1 is fresh. Instead of timestamp, the user can send a request containing sequence number. 1. U → SEM : M ACk (m, T S1 ), m, T S1 , IDu 2. SEM → U : M ACk (P Ssem , T S2 ), P Ssem , T S2 – Security The SEM sets a time α. Only if T ≤ T S1 +α, where T is the time of receiving request, the SEM can accept this request. – Efficiency The computational and communicational costs are the same as those of traditional method. 6 Conclusions The traditional SEM approach has the disadvantage that it is vulnerable to DoS attacks, since an attacker can send a lot of requests to the SEM server. To prevent DoS attacks, some solutions are proposed. However, these approaches cannot prevent DoS attacks. This paper proposes Security-Mediated PKI using one- time ID. Our proposed system can avoid DoS attacks with small computational complexity. Additionally, our proposed system can protect the privacy of signers, since one-time ID can be used only once. Suppose that the SEM’s partial private key dsem is compromised. If a revoked user colludes with an attacker who obtains dsem , a revoked user can generate a signature. This is the security issue in traditional SEM. Our future work is to improve this issue. References 1. K. Bicakci, and N. Baykal, “A New Design of Privilege Management Infrastructure with Binding Signature Semantics,” 1st European PKI Workshop (EuroPKI 2004), LNCS 3093, pp. 306–313, Springer-Verlag, 2004. 2. D. Boneh, X. Ding, G. Tsudik, and C. M. Wong, “A Method for Fast Revocation of Public Key Certificates and Security Capabilities,” In proceedings of the 10th USENIX Security Symposium, pp. 297–308, 2001. 3. D. Boneh, X. Ding, and G. Tsudik, “Fine-grained Control of Security Capabilities,” ACM Transactions on Internet Technology (TOIT), Volume 4, pp.60–82 , 2004 4. C. Boyd, “Digital multisignatures,” Cryptography and Coding, Oxford University Press, pp. 241–246, 1989. 5. E. Bresson, O. Chevassut, and D. Pointcheval, “New Security Results on Encrypted Key Exchange,” International Workshop on Practice and Theory in Public Key Cryptography (PKC 2004), LNCS 2947, pp.145-158, 2004. 6. R. Housley, W. Polk, W. Ford, and D. Solo, “Certificate and Certificate Revocation List (CRL) Profile,” IETF RFC3280, 2002. http://www.ietf.org/rfc/rfc3280.txt 7. K. Imamoto, and K. Sakurai, “A Design of Diffie-Hellman Based Key Exchange Using One-time ID in Pre-shared Key Model,” The 18th International Conference on Advanced Information Networking and Applications (AINA 2004), pp. 327–332, 2004. 8. ITU/ISO Recommendation. X.509 Information Technology Open Systems Intercon- nection - The Directory: Authentication Frameworks, 1997. 9. H. Krawczyk, “The IKE-SIGMA Protocol,” Internet Draft, 2001. http://www.ee.technion.ac.il/ hugo/draft-krawczyk-ipsec-ike-sigma-00.txt 10. H. Krawczyk, M. Bellare, and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” IETF RFC2104, 1997. http://www.faqs.org/rfcs/rfc2104.html 11. R. Labs, “PKCS #1v2.1: RSA cryptography standard. Tech. rep.,” RSA Labora- tories, 2002. 12. K. Matsuura, and H. Imai, “Modified Aggressive Mode of Internet Key Ex- change Resistant against Denial-of-Service Attacks,” IEICE TRANS. INF.&SYST., Vol.E83-D, No.5, pp.972-979, 2000. 13. M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, “X.509 Inter- net Public Key Infrastructure Online Certificate Status Protocol-OCSP,” IETF RFC2560, 1999. http://www.ietf.org/rfc/rfc2560.txt 14. G. Vanrenen, and S. Smith, “Distributing Security-Mediated PKI,” 1st European PKI Workshop (EuroPKI 2004), LNCS 3093, pp. 218–231, Springer-Verlag, 2004. On Securing the Public Health Information Network Messaging System Barry Rhodes Rajashekar Kailar Associate Director For Public Health System Development Chief Technology Officer Information Resources Management Office Business Networks International, Inc. Centers for Disease Control and Prevention www.bnetal.com www.cdc.gov Abstract The Public Health Information Network PHINMS is operating system neutral since it is Messaging System (henceforth, PHINMS) is the implemented using Java and J2EE standards. Centers for Disease Control and Prevention’s (CDC) implementation of the ebXML 2.0 Further, it provides language neutral, queue based messaging standards [EbXML]. This system was interfaces for sending and receiving messages. The developed for the purpose of secure and reliable preferred queue implementation is an messaging over the Internet. This software has ODBC/JDBC compliant database table, but been widely deployed by CDC and its public support for queues based on XML file descriptors health partners, including state and local health also exists. PHINMS supports peer-to-peer departments, and healthcare providers. PHINMS is messaging, as well as messaging via a third party designed to leverage X.509 digital certificates using a send and poll model. issued by public key infrastructures, but does not require a single, universal PKI. In this paper we Message data security is accomplished using a discuss some of the security aspects of PHINMS. combination of encryption, end-point authentication, and access control techniques. Transport reliability is accomplished using Introduction message integrity verification, transmission retries and duplicate detection on message receipt. The Public Health Information Network Since PHINMS is used to transport sensitive data Messaging System (PHINMS) is a CDC over public un-trusted networks (e.g., Internet), it developed implementation of existing standards is important to make sure that end-points trust for the secure and reliable transmittal of messages each other, are able to identify and authenticate across the Internet. each other, and that communication channels preserve data confidentiality and integrity. Further, The PHINMS relies on ebXML, XML encryption access to data sent and received should be [XMLENC], XML Digital Signature [XMLDSIG], controlled. SOAP [SOAP] and other standards. PHINMS is the primary message transport system for the The balance of this paper will focus on some of National Electronic Disease Surveillance System the security considerations that went into the [NEDSS], the Laboratory Response Network design and implementation of PHINMS. [LRN], National Health Safety Network [NHSN] and various other public health preparedness programs within CDC. By design, PHINMS is message data (payload) independent; hence it can be used to transport any type of data (e.g., text, binary). Security Considerations Several security considerations went into the and trust authority may not be politically design, implementation and deployment of acceptable. In a purely PKI based authentication PHINMS. The following is a brief description: framework, a trust bridge such as the Federal Bridge CA could be used to address this problem. However, while PHINMS supports Trust1 PKI based authentication, it also supports other Secure messaging over public un-trusted modes of authentication, such as basic or custom networks requires messaging parties to be able authentication. to identify, authenticate and trust each other. For this, firstly, real world trust relationships need to PHINMS is designed to support both centralized be established between messaging organizations. and de-centralized trust models. Decisions on This may include establishing written identity binding and security credentialing are agreements on service levels, liabilities, etc., made by the deploying organizations. Decisions pursuant to OMB guidance on the Government on trusting the identity and security credentials Paperwork Elimination Act (GPEA) as well as are made mutually between messaging parties at the Electronic Signatures in Global and National the time when electronic collaborations are Commerce Act (E-SIGN). Further, business created. processes for creating and handling messages at each end of the messaging pipe need to be put in place. Once trust and business relationships are Identification, Authentication and established in real world terms, electronic Authorization collaboration agreements can be setup for message transport and processing. This includes Identification and authentication in messaging is setting up relationships to trust certification a difficult topic and is one that is far from authorities and the identity of the sending and mature. Since the message is typically sent by a receiving components (e.g., using access control process and not necessarily triggered by an lists). individual, the authentication dialog must be scriptable. That is, the sending application must be able to negotiate the exchange of credentials In a centralized trust model, a central node without human intervention. This is only performs identity binding and security possible for certain security tokens (e.g., credentialing, and all nodes establish trust hardware based one time passwords and relationships with a central node. In this case, biometric identities don’t lend themselves to this assuming n nodes, only O(n) trust relations are kind of scripted authentication exchange). needed. However, in a heterogeneous environment where trust is de-centralized, with n PHINMS supports automated authentication nodes, each node may need to establish a trust dialogs for client-certificate based authentication relationship and security credentials with every over SSL, basic authentication, and form based other node, and in the worst case scenario O(n2) authentication. The method used for mutual and trust relationships may be needed. Since automated identification and authentication messaging nodes typically belong to between messaging parties is part of the autonomous organizations and realms, electronic agreement between them, and should establishing a globally accepted central identity be established upfront, after the real world trust relationship has been established. 1 “Trust” in this context is more generic than what is involved in PKI based certificate chain validation. In particular, it may involve other (non-PKI) authentication mechanisms (e.g., basic or form based authentication). Organization A Organization B PHINMS Receiver Server A PHINMS Security Credential P Sender WEB PHINMS SERVER Receiver PHINMS (PROXY) Sender Security Credential Q PHINMS Transport DMZ Receiver Queue Worker Server B Queue Firewall Internet Firewall Each messaging node in the Public Health The web-server proxies typically reside in the Information Network (PHIN) is identified by a organization’s DMZ, and mediate all inbound globally unique identifier. As shown in the traffic for the PHINMS receiver server, diagram above, a messaging node (i.e., PHINMS authenticating the sending process. SSL with sender) may contain one or more security client-certificate based authentication is the credentials that allow it to conduct automated preferred method of authentication for PHINMS, authentication dialogs with other messaging since it is a well established standard and is nodes. In the absence of a universally trusted widely implemented by web-server proxies. authority to issue security identities and credentials, potentially, a different security identity and set of credentials may be needed for Once the message sender is authenticated, it is the purpose of authenticating to each message the responsibility of the receiving organization’s destination. The security credentials may include web-server proxy to ensure that an authenticated client certificates (key-stores), passwords, etc. sender only gains access to the receiver URL. At Managing these security credentials can be a this time, PHINMS does not provide support for daunting task for the messaging administrator in attribute certificates which can be used for the face of expiring certificates, password authorization decisions. Authorization renewals etc. While certificates can be issued information is stored on the receiver server, and with an expiration period of years, passwords enforced by the web-server proxy based on the typically must be changed every 90 days, so the authenticated identity of the PHINMS senders. problem with the latter is far more daunting. Authentication Factors The recommended architecture for PHINMS For interactive authentication dialogs over the messaging is one where the PHINMS receiver Internet, generally, two factor authentication2 is components are protected from direct access considered stronger and more secure than single from the Internet, by web-server proxies as factor authentication. shown in the diagram at the top of the next column: 2 Authentication mechanisms typically use secrets such as what a user knows (e.g., password), what a user has (e.g., hardware token) and what a user is (e.g., thumbprint). These are called authentication factors. For strong authentication, a combination of two of these three factors is used. However, in the case of B2B automated In the case of store and forward messaging, data security dialog, the security value of two- is protected from being read by intermediaries factor authentication is significantly by using asymmetric encryption using the public diminished, since there is no real user key of the message recipient to encrypt a random symmetric key, which in turn encrypts behind the authentication dialog. All user the data. Additionally, communication is factors required for the authentication typically conducted over a Secure Sockets Layer dialogs would need to be pre-configured into (SSL) channel, ensuring that the message meta- the software that initiates the authentication data is also protected. To ensure end-to-end handshake. Further, at the time of this confidentiality, the channel between the web- writing, there are no published and accepted server proxy and the application server is also Internet standards for two factor over SSL. authentication in B2B transactions. While it is possible to use hardware based security modules (sometimes called HSM) to Integrity and Non-repudiation emulate additional authentication factors for PHINMS supports the use of XML digital B2B exchanges, such mechanisms require signatures [XMLDSIG] for message integrity additional hardware and management and non-repudiation of message data. Signing complexity. certificates can be sent as part of the signature meta-data facilitating verification of the signature, alternatively, signing certificates can Confidentiality be statically pre-configured at the receiving Since communication is over un-trusted public node. Additionally, communication is typically networks, protecting its confidentiality is conducted over SSL with client-certificate based important. PHINMS uses payload level authentication, which provides further message asymmetric encryption for end-to-end persistent integrity and non-repudiation assurances. confidentiality. The XML encryption standard The XML encryption standard [XMLENC] is used for encrypting the payload. Access Control The ebXML messaging Message Message standard supports message Sending Service=X Application Receiving labels called “Service” and Application Action=Y In-Queue A Application A “Action”. These XML tags are part of the message envelope, and can be mapped to a Out-Queue service on the receiving node. Message Message PHINMS Service=P Application Receiving Receiver PHINMS (Service=X, Action=Q In-Queue B Application B In the PHINMS Action=Y) Sender implementation, messages that are received using the receiver server are stored in database tables (queues) based on their Service and Action tags. These Message queues are the equivalent of an Service=M Application Receiving application “inbox”, and each Action=N In-Queue C Application C application can only access its own inbox. Public Key Infrastructure (PKI) Firewalls PHINMS is designed to leverage a PKI, but it does not require a universal PKI. For instance, a Though firewalls are necessary for the PHINMS sending client can use a client protection of resources within an enterprise, they certificate issued by one certification authority complicate matters for a messaging system (CA) to authenticate itself to a PHINMS receiver trying to send messages across enterprise server, and use a client certificate issued by a boundaries. PHINMS uses two independent different CA to authenticate itself to a different pieces of code, a client capable of sending PHINMS receiver server. Currently, PKI trust messages and receiving real time (synchronous) relations are statically defined at the time when responses, and a server receiver that can receive collaboration is established and configured messages at any time. These two components between messaging entities. This is sometimes may be used in three possible scenarios. These called the “Certificate Trust List” model. examples assume that the parties are in different organizations with separate firewalls. Ideally, public key certificates are published in 1. Both parties are located outside their an LDAP directory (need not be centralized), but respective firewalls (i.e., in their DMZ) PHINMS also supports a web-service interface 2. One party is outside the firewall and the to publish and retrieve certificates. As a third other is inside a firewall. alternative, encryption public key certificates 3. Both parties are inside their respective can be distributed out of band and pre- firewalls. configured at the message sending nodes. Public key certificates can be published in de- centralized LDAP directories as well. In the case where both parties are located the server can return the file as a response to the outside their respective firewalls, messages may send. Because the client is not really receiving be sent and received at any time and messages, the complexity of the software is acknowledgements send either synchronously or reduced and therefore the platform requirements asynchronously. This requires that both parties are reduced as well. have sending and receiving components installed. Typically the client can reside on a workstation capable of hosting a Java application. Firewall DMZ DMZ Firewall Intermediate Party Send Firewall PHINMS DMZ PHINMS PHINMS Send Send/Poll Send/Poll DMZ DMZ Firewall Intranet Intranet PHINMS PHINMS Scenario 1: Both parties are Internet accessible (i.e., in DMZ) Firewall Scenario 3: Both parties behind firewalls For the situation where one party is behind a firewall and the other party has a server receiver In the case where both parties are behind located in the public Internet space, message firewalls, a third party server with Internet sending options are slightly reduced. The client presence is required to broker the exchange. For piece behind the firewall can send data much example let’s say party A is located behind a like a typical browser to a receiver and receive firewall in enterprise 1 and A wants to send a synchronous acknowledgements back. message to party B in enterprise 2, where B is also behind a firewall. Then A must send a Because it sits behind a firewall, the client message to an intermediary server on the cannot receive messages as firewalls typically Internet with a service action that states that the block this type of “push” of information. What server should hold the message in a queue for B. it can do is poll for messages. Then when B polls the server, it will find the message from A in its queue and request it. Intranet DMZ DMZ Intranet Authentication Interoperability Poll The ebXML messaging standard specifies the PHINMS PHINMS structure and semantics of message meta-data and addressing information, but for the most Send part, leaves the messaging security (identification and authentication) aspects to the Firewall Firewall implementers. Scenario 2: One party is behind firewall Basically a poll is where a client sends a message to a server with some meta-data which maps to a piece of functionality that looks to see if the server has something for the client. If so, When used, XML digital signatures should be ebXML Interoperable ebXML combined with a handshaking protocol such as Implementation P Implementation Q SSL, which mitigates the threat of replay attacks Security Security and provides freshness assurances. The Non-Interoperable Mechanism A Mechanism B alternative is to use SSL with client certificate Messaging not interoperable based authentication. This provides per-link assurance of identity and authentication, as well ebXML Interoperable ebXML as confidentiality. Since SSL is the most widely Implementation P Implementation Q accepted standard, this is the recommended Security Interoperable Security mode of authentication for PHINMS. Mechanism C Mechanism B Messaging interoperable Acknowledgements The authors would like to thank the Public As shown in the above diagram, for Health Information Network Messaging System interoperability, in addition to the message team: Michele Bowman, Thomas Brinks, structure and semantics, the security Dongtao Jiang, Vaughn McMullin, Thomas mechanisms also need to interoperate. XML Russell, and John Thomas. digital signatures can be used to support message non-repudiation (the strength of which is dependent upon legal elements that Summary transcend the technology), but using them may not be sufficient for the purpose of The security design, implementation and authenticating clients to sensitive deployment considerations of CDC’s Public Health Information Network Messaging System applications unless its freshness is (PHINMS) were discussed herein. established. Without adequate freshness assurances use of DSIG in authentication may not be adequate for some applications. References [EbXML] Message Service Specification [NHSN] National Healthcare Safety Network (NHSN)(http://www.cdc.gov/ncidod/hip/NNIS/mem Version 2.0, OASIS ebXML Messaging Services bers/nhsn.htm ) Technical Committee (http://www.ebxml.org/specs/ebMS2.pdf) [SOAP] SOAP Version 1.2 Part 0: Primer [LRN] The Laboratory Response Network Partners (http://www.w3.org/TR/2003/REC-soap12-part0- in Preparedness http://www.bt.cdc.gov/lrn/ 20030624/ ) [NEDSS] National Electronic Disease Surveillance [XMLENC] XML Encryption Requirements System, The Surveillance and Monitoring (www.w3.org/TR/xml-encryption-req) Component for the Public Health Information Network. (www.cdc.gov/nedss/) [XMLDSIG] XML-Signature Syntax Processing (www.w3g.org/TR/xmldsig-code On Securing the Public Health Information Network Messaging System Barry Rhodes, Ph.D. Rajashekar Kailar, Ph.D. Associate Director Chief Technology Officer Public Health System Development Business Networks International Inc. NCPHI www.bnetal.com Centers for Disease Control and Prevention www.cdc.gov Overview  Public Health Information Network (PHIN)  PHIN Messaging System (PHINMS)  Security considerations  Public Key Infrastructure considerations Public Health Information Network (PHIN) (www.cdc.gov/phin/)  Public health organizations  CDC  State, Local Health Departments  National Laboratories (e.g., LabCorp)  Standards based information gathering and dissemination across organizations (routine surveillance, emergency event response)  Data gathering: NEDSS Data Model, PAMs  Message content: HL7  Data transport: ebXML over HTTP(S) Electronic Business XML (www.ebxml.org) XML Standard for B2B electronic document exchanges  SOAP with Attachments  Reliable (once and only once delivery)  Message level security (XMLENC / XMLDSIG)  Standard message envelope, addressing schema / semantics  Workflows (Service, Action) PHIN - Operational Environment PHIN Messaging System  Secure and Reliable Transport over Public Networks  Security: Confidentiality, Integrity, Non-Repudiation, Authentication, Access Control  Reliability: Once and only Once delivery, network failure handling  Standards Based  ebXML/HTTPS, X.509, XMLDSIG, XMLENC  Platform Neutral  Java/J2EE  Language Neutral  Queue Interfaces (database tables)  Payload agnostic (text, binary)  Extensible  Message handlers  Certified for ebXML interoperability with several ebXML products by Drummond Group PHINMS - Functional Components Message PHINMS Application Sender Response Application1 Message (Message Handler) PHINMS Receiver Respons Application2 e (Message Handler) Messaging Security Context  Sensitive data  Public, un-trusted networks (Internet)  Autonomous organizations  Heterogeneous environments  Public health users not always security savvy Business/Electronic Collaboration Agreements State Lab State HD Client Client Server Server CDC Client Server Hospital National System Labs Client Client No central identity/trust authority PKI and non-PKI environments PHINMS – Messaging/Trust Models Hub-and-Spoke (route-not-read) Peer-to-Peer (direct-send) Confidentiality – Transport and Message Level LDAP State Lab DOH DOH Public Key DOH (Encrypt) Private Key HL7 (Decrypt) Internet HL7 Proxy PHINMS PHINMS Server Server DB Client Q DB DMZ Q Firewall Firewall Integrity: Transport and Message Level State Lab Lab DOH Private Key (Sign) Lab HL7 Public Key Internet (Verify) HL7 Proxy PHINMS PHINMS Server Server DB Client Q DB DMZ Q Access Control: Perimeter Level DMZ Internal Network Internal Network Proxy PHINMS Message Server Receiver Consumer Internet PHINMS ACL Sender Firewall Firewall Firewall Identities, Credentials, Authorities PHINMS Receiver Server A Security Credential P PHINMS Sender Security Credential Q PHINMS Receiver Server B Accept Multiple Credentials Submit Multiple Credentials (policy dependent) Identity: Party ID Credential: Certificate, Password Access Control: Message Level End Point Authentication Two factor: Appropriate for user interactions 2 Factor for B2B – No inter-op standards, Lower assurance ROI Firewall Considerations Scenario 1: Both parties are Internet Accessible Firewall Considerations (Contd.) Scenario 2: One party behind firewall Firewall Considerations (Contd.) Scenario 3: Both parties behind firewalls Interoperability Use of PKI in PHIN MS  Leverages PKI for security, but does not require it  Authentication  Client certificate over SSL (enforced by web server proxy using CTL model)  Currently not Bridge PKI aware (proxy layer can be extended)  XML Encryption  Certificate lookup from LDAP Directory  Certificate lookup using web service  XML DSIG  Signature meta-data includes X.509 certificate PHIN Partners – PKI Landscape  PKI Implementers (few)  Organizations with full PKI implementation  PKI Users (most)  SSL servers/certificates (most)  User certificates, strong authentication (few)  Mixed environments - PKI and non-PKI (most)  Purely non-PKI (few)  Organizations that use other mechanisms (e.g., login/password, one time password) PHINMS – Status  Used by several CDC/PHIN applications as primary data transport mechanism over Internet  Deployed in 50+ sites nationwide, many more being deployed  Processes thousands of production messages daily  Data is transported securely and reliably - gracefully handles network failures using persistence/retries PHINMS - Lessons Learned  ebXML, Web-Services Security Standards are a moving target  Multiple credentials/mechanisms a reality today  Managing multiple credentials a challenge (e.g., expiring passwords, certificates) Questions? PKI, Security, and Health Care Rich Guida Director, Information Security Oct 2004 - 1 What is the Health Care “Space?” • Point-of-care providers (doctors, clinics, hospitals) • Consumers (who receive the care) • Insurers • Product companies • Research institutions • Governments Oct 2004 - 2 Another way to parse the space • Those who typically process patient data (as Personal Health Information – PHI)  Point-of-care facilities  Insurers  Some research institutions • Those who typically do not process patient data (as PHI – instead, anonymized)  Most product companies and governments (other than for their own employees) Oct 2004 - 3 Applicable Federal Laws/Regulations • Health Insurance Portability and Accountability Act (HIPAA)  Confidentiality and integrity of patient data (including PHI) • FDA 21 CFR Part 11  E-records and e-signatures • FDA “Computer Systems Validation” guidance • Government Paperwork Elimination Act (GPEA) • Electronic Signatures in Global and National Commerce Act (E-SIGN) Oct 2004 - 4 Examples of Important Processes • Clinical trials of new drugs/devices  Data integrity/authenticity, and where PHI is involved, confidentiality • Maintaining quality assurance records on manufacturing and management  Data integrity/authenticity • Product distribution  Data integrity/authenticity – to guard against counterfeits • Billing (insurers/point-of-care providers)  All of the above Oct 2004 - 5 Healthcare Security Today • Mostly userID/password-based for authentication and e-signatures  But strong movement towards certificate- based in many areas • Diverse environments mean diverse operating systems and practices • Health care as a whole is still evolving towards “strong computer security” principles Oct 2004 - 6 Goals in Using Certificates • Single, unified identity for healthcare providers, globally recognized  Note: NOT patients! • Stronger e-signatures, authentication, encryption • Accelerate processes of getting drugs/devices through clinical trials – by reducing paperwork Oct 2004 - 7 Today’s Panel • Terry Zagar from SAFE  To discuss the industry-wide initiative focusing on unified credentials based on PKI  Includes discussion of SAFE Bridge CA effort • John Landwehr from Adobe  To discuss how Adobe 6.0 and 7.0 fit in to SAFE’s activities with native PKI functionality Oct 2004 - 8 SAFE Public Key Infrastructure (PKI) Terry Zagar Chair, SAFE Operations & Technology Working Group April 21, 2005 1 Topics  SAFE & Biopharmaceutical Community  SAFE Community Framework  Architecture Drivers  SAFE Architecture  Certificate/OCSP Structure  Building Understanding & Conformance  Future SAFE Directions 2 SAFE & Bio-Pharmaceutical Community MAY 2003 SAFE  strategic CONCEPT PhRMA initiative  Trusted e-identity credentials  Closed contractual system DEC 2003 Seed investment  12  Accredited bio-pharmaceuticals  Business focus JUN 2003 SAFE Standard v1.0 DRIVERS  Regulatory compliance DEC 2004 SAFE-Biopharma  8  Business efficiency bio-pharmaceutials  Cost savings JUN 2005 SAFE Bridge IOC & [planned] SAFE Standard v2.0 3 SAFE Community Framework SAFE-Biopharma Agreement SAFE Standard Agreement • Business/Legal • Governance Member • Specifications Issuer Full Services Services • For-Profit Entities • SAFE Bridge CA • CA / RA / CSA • Not-For-Profit Entities • Directory • Credentials for Members • Government Orgs • Issuer Services for • Identity Proofing Medical Associate Practitioners/Others • Medical Practitioners • Other Entities/Individuals designated by SAFE Agreement 4 SAFE Architectural Drivers  High trust system  Pre-existing Member PKIs  Minimum of reinvention  Regulatory compliance  Move burden from user to infrastructure  Do not preclude other uses  What time is it in …? 5 SAFE Architecture SAFE Issuer CP Registration and Certificate Management Systems OCSP OCSP Cross SAFE SAFE Request Response Certificates Certificate Certificate OCSP SAFE Cert. Response Authentication Subscriber SAFE- Biopharma SAFE Bridge Central End-User Machine CA Systems Systems Systems OCSP CP Request Validation Signing & Validation Signing & Validation OCSP OCSP Request & Request & Request & Request Response Response Response Response SAFE Member SAFE Enabled Applications CP Details contained in associated Details contained in SAFE CP Technical Specification 6 Key SAFE Certificate & OCSP Features SAFE Subscriber Certificate  Issuer & Subject Distinguished Name field  Subject Alternate Name extension  Key Usage extension  Authority Information Access extension  Certificate Policies extension SAFE OCSP Request/Response  SAFE certificate validation must use OCSP  OCSP Responder must accept unsigned requests  Nonce required for digital signature validation purposes only 7 Building Understanding & Interoperability  Participation – Member working groups – Member control mechanisms – Member tools – Issuers, Infrastructure providers, Application vendors, Integrators  Accreditation – Members – Issuers  Certification – Application vendors – Infrastructure providers – Integrators 8 Future SAFE Directions  Easing SAFE application enablement – API Specification between applications and certificate validation software/services – API Specification between applications and smart card/token middleware  Verifying SAFE application enablement – Designation of independent certification test labs  Supporting other uses for SAFE identity – SAFE specifications/guidance for authentication uses 9 Discussion 10 Digital Signature Update Acrobat / Reader 7.0 John T. Landwehr, CISSP Director, Security Solutions and Strategy Adobe Systems Incorporated Digitally signed by John Landwehr Date: 2005.04.20 19:46:26 -07'00' 2005 Adobe Systems Incorporated. All Rights Reserved. bc Digital Signature Capabilities ƒ Available since Acrobat 4.0 in 1999 ƒ Signature pads, smartcards, biometrics ƒ Author signatures to certify one-way publishing and form content ƒ Recipient signatures to give legally- enforceable assurance of receipt 2005 Adobe Systems Incorporated. All Rights Reserved. 2 bc Why certify a document? ƒ Recipient knows that form appearance is authentic and unmodified ƒ Per customer requests, it also includes signing the business logic in the form ƒ e.g. Calculations and where the form is sent when the submit button is pressed ƒ Upon return, author knows their form hasn’t been altered ƒ Adobe recommends that all forms and round-trip communications be certified to limit phishing and personal information leakage Certify Verify Author Recipient(s) Verify, Verify Sign 2005 Adobe Systems Incorporated. All Rights Reserved. 3 bc Two Recipient Signatures Certified 2005 Adobe Systems Incorporated. All Rights Reserved. 4 bc Form Signing With In-line Signatures ƒ Unlike other formats and applications, signatures are applied inline – just like paper ƒ No user retraining required to find signature field ƒ Appearance supports text and images, e.g. handwritten signature, photo, etc. ƒ Audit history also contained within document Most other approaches require users to sign a “wrapper” in an external window 2005 Adobe Systems Incorporated. All Rights Reserved. 5 bc Signature properties ƒ Signature fields on forms/documents can require certain parameters before a signature will be allowed, e.g. ƒ Certificate under a particular Root ƒ Certificate has a particular OID (e.g. SAFE) ƒ Reasons for signing (e.g. “This is a SAFE signature”) ƒ If signer doesn’t have a matching cert, they can’t sign the form, and are redirected to a specified URL for more information (e.g. registration information) 2005 Adobe Systems Incorporated. All Rights Reserved. 6 bc Current Security Partners http://partners.adobe.com/security/ 2005 Adobe Systems Incorporated. All Rights Reserved. 7 bc What’s new with 7.0? 2005 Adobe Systems Incorporated. All Rights Reserved. 8 bc New validation engine ƒ Provides consistent results across platforms and versions ƒ Core crypto from RSA BSAFE toolkits with certifications ƒ Certificate validation/processing designed by Adobe ƒ Independent of release, service packs, and hotfixes in OS ƒ Windows, Mac, and now Linux too ƒ Great for workflows outside your organization where you have no idea what OS version the signer has ƒ MSCAPI is still an option on Windows ƒ Signing (private key ops) via CSPs still supported ƒ CAPI Validation and Root Store turned off by default, but can be turned on if desired 2005 Adobe Systems Incorporated. All Rights Reserved. 9 bc New Native Capabilities ƒ OCSP ƒ Timestamping via RFC3161 ƒ Certs from bridge CAs ƒ XML Signatures ƒ Embed revocation info at signing ƒ SHA256 verification ƒ PKCS#11 support for tokens 2005 Adobe Systems Incorporated. All Rights Reserved. 10 bc 2005 Adobe Systems Incorporated. All Rights Reserved. 11 bc 2005 Adobe Systems Incorporated. All Rights Reserved. 12 bc Third Party Tests ƒ NIST PKI Test Suite (PKITS) http://csrc.nist.gov/pki/ ƒ We pass the 250+ tests ƒ DoD JITC Certified http://jitc.fhu.disa.mil/pki/vendor/adobe_acrobat_7_0_pro.html ƒ Test completed. All tests passed. ƒ FIPS 201 cards ƒ Evaluation underway 2005 Adobe Systems Incorporated. All Rights Reserved. 13 bc Signing non-PDF content ƒ Other file types can now be easily attached to a PDF form and included in the digital signature workflow 2005 Adobe Systems Incorporated. All Rights Reserved. 14 bc Acrobat vs Reader ƒ Verification is always available in Acrobat & Reader ƒ Signing is available in Acrobat Standard & Acrobat Professional ƒ Signing is optionally available in Adobe Reader (Win, Mac, Linux) when the form has been enabled with Adobe LiveCycle Reader Extensions 2005 Adobe Systems Incorporated. All Rights Reserved. 15 bc New Server Capabilities ƒ Adobe LiveCycle Security Server ƒ J2EE-based server ƒ Signs/validates ƒ Encrypts/decrypts ƒ For automated/batch workflows Server A: Server can Certify form A D G B: Verify A C: User 1 Signs D: Server verifies A + C E: User2 Verifies A + C B C E F F: User 2 Signs User1 User2 G: Server verifies A + C + F 2005 Adobe Systems Incorporated. All Rights Reserved. 16 bc bc 2005 Adobe Systems Incorporated. All Rights Reserved. 17 bc