MOSAIC. UPENET (UPGRADE European NETwork)

Transcription

1 UPGRADE is the European Journal for the Informatics Professional, published bimonthly at < UPGRADE is the anchor point for UPENET (UPGRADE European NETwork), the network of CEPIS member societies publications, that currently includes the following ones: Mondo Digitale, digital journal from the Italian CEPIS society AICA Novática, journal from the Spanish CEPIS society ATI OCG Journal, journal from the Austrian CEPIS society OCG Pliroforiki, journal from the Cyprus CEPIS society CCS Pro Dialog, journal from the Polish CEPIS society PTI-PIPS Publisher UPGRADE is published on behalf of CEPIS (Council of European Professional Informatics Societies, < by Novática < journal of the Spanish CEPIS society ATI (Asociación de Técnicos de Informática, < UPGRADE monographs are also published in Spanish (full version printed; summary, abstracts and some articles online) by Novática, and in Italian (summary, abstracts and some articles online) by the Italian CEPIS society ALSI (Associazione nazionale Laureati in Scienze dell informazione e Informatica, < and the Italian IT portal Tecnoteca < UPGRADE was created in October 2000 by CEPIS and was first published by Novática and INFORMATIK/INFORMATIQUE, bimonthly journal of SVI/FSI (Swiss Federation of Professional Informatics Societies, < Editorial Team Chief Editor: Rafael Fernández Calvo, Spain, <rfcalvo@ati.es> Associate Editors: François Louis Nicolet, Switzerland, <nicolet@acm.org> Roberto Carniel, Italy, <carniel@dgt.uniud.it> Zakaria Maamar, Arab Emirates, <Zakaria. Maamar@ zu.ac.ae> Soraya Kouadri Mostéfaoui, Switzerland, <soraya.kouadrimostefaoui@unifr.ch> Editorial Board Prof. Wolffried Stucky, CEPIS Past President Prof. Nello Scarabottolo, CEPIS Vice President Fernando Piera Gómez and Rafael Fernández Calvo, ATI (Spain) François Louis Nicolet, SI (Switzerland) Roberto Carniel, ALSI Tecnoteca (Italy) UPENET Advisory Board Franco Filippazzi (Mondo Digitale, Italy) Rafael Fernández Calvo (Novática, Spain) Veith Risak (OCG Journal, Austria) Panicos Masouras (Pliroforiki, Cyprus) Andrzej Marciniak (Pro Dialog, Poland) English Editors: Mike Andersson, Richard Butchart, David Cash, Arthur Cook, Tracey Darch, Laura Davies, Nick Dunn, Rodney Fennemore, Hilary Green, Roger Harris, Michael Hird, Jim Holder, Alasdair MacLeod, Pat Moody, Adam David Moss, Phil Parkin, Brian Robson Cover page designed by Antonio Crespo Foix, ATI 2005 Layout Design: François Louis Nicolet Composition: Jorge Llácer-Gil de Ramales Editorial correspondence: Rafael Fernández Calvo <rfcalvo@ati.es> Advertising correspondence: <novatica@ati.es> UPGRADE Newslist available at < Copyright Novática 2005 (for the monograph and the cover page) CEPIS 2005 (for the sections MOSAIC and UPENET) All rights reserved. Abstracting is permitted with credit to the source. For copying, reprint, or republication permission, contact the Editorial Team The opinions expressed by the authors are their exclusive responsibility Vol. VI, issue No. 4, August 2005 Monograph: Standardization for ICT Security (published jointly with Novática*) Guest Editors: Paloma García-López, Stefanos Gritzalis, and Javier López-Muñoz 2 Presentation ICT Standardization: An International and Cross-sectorial Task Paloma García-López, Stefanos Gritzalis, and Javier López-Muñoz 4 Where Do the Voluntary Standards and Recommendations Regarding Information Security Come From? Paloma García-López 13 CEN/ISSS and Its Contribution to European Standardization in Security of Information Technologies Luc Van den Berghe 17 International Standardization of Information and IT Security - Current and Future SC27 Activites Ted Humphreys 22 Common Criteria International Standards Miguel Bañón 28 Security Metrics and Measurements for IT José A. Mañas- Argemí 31 IT Security Audits from A Standardization Viewpoint Marina Touriño-Troitiño 36 Legislation, Standards and Recommendations Regarding Elec tronic Signature Josep-Lluís Ferrer-Gomila and Apol lònia Martínez- Nadal 41 The X.509 Privilege Management Standard David Chadwick 47 ICT Security Standards for Healthcare Applications Spyros Kokolakis and Costas Lambrinoudakis MOSAIC 55 Web Services QoS Information & Computation (QoS-IC) Framework for QoS-Based Discovery of Web Services Laila Taher, Rawshan Basha, and Hazem El Khatib UPENET (UPGRADE European NETwork) 67 From Novática (ATI, Spain) Software Patents Ariba versus eplus: A Software Patent Lawsuit in The USA Llorenç Pagés-Casas ISSN Monograph of next issue (October 2005): Ubiquitous Computing (The full schedule of UPGRADE is available at our website) * This monograph will be also published in Spanish (full version printed; summary, abstracts, and some articles online) by Novática, journal of the Spanish CEPIS society ATI (Asociación de Técnicos de Informática) at < and in Italian (online edition only, containing summary, abstracts, and some articles) by the Italian CEPIS society ALSI (Associazione nazionale Laureati in Scienze dell informazione e Informatica) and the Italian IT portal Tecnoteca at <

2 The X.509 Privilege Management Standard David Chadwick This paper provides an overview of Privilege Management Infrastructures (PMIs), as standardised in the 2001 edition of X.509. It briefly compares PMIs to PKIs (Public Key Infrastructures) and then describes how an X.509 PMI was first implemented in the PERMIS authorisation infrastructure. The paper highlights many features of a practical PMI implementation that were not part of the X.509 (2001) standard, and that had to be solved in the PERMIS implementation. Many of these features are now being or already have been specified in recent standards from OASIS (Object-Oriented Administrative Systems-development in Incremental Steps), the IETF (Internet Engineering Task Force), the GGF (Global Grid Forum), and the forthcoming 2005 edition of X.509. The paper also points out several features that still remain to be standardised. Keywords: Attribute Certificates, Authorisation, PMI, Privilege Management, Privilege Policies, Standardisation, X Privilege Management in X.509(2001) Most people today have some familiarity with X.509 Public Key Certificates (PKCs). They are ubiquitous for secure web communications, being mandatory for establishing SSL (Secure Sockets Layer, connections with web servers. X.509 PKCs, and their controlling Public Key Infrastructures (PKIs) are used to strongly authenticate communicating parties and they were first standardised in Since then, there have been 3 revisions to the X.509 standard, producing successive refinements to the PKI model and its certificates. These revisions were published in 1993, 1997 and 2001 [22] saw the first introduction of a strong authorisation infrastructure to compliment the public key authentication infrastructure. Known as a Privilege Management Infrastructure (PMI), PMIs have many similarities with PKIs. This paper assumes that the reader is already familiar with the general concepts of PKIs, and these will not be repeated here. Readers wishing to learn more about PKIs may consult texts such as [1] or [2]. The primary data structure in a PMI is an X.509 Attribute Certificate (AC) (Figure 1) This strongly binds a set of attributes to its holder, and these attributes are used to describe the various privileges of the holder bestowed on it by the issuer. The issuer is termed an Attribute Authority (AA), since it is the authoritative provider of the attributes given to the holder. Examples of attributes and issuers might be: a degree awarded by a university, an ISO 9000 certificate issued by a QA compliance organisation, the role of 1 A General Name can be chosen from many different ways of identifying an entity, such as its: X.500/LDAP distinguished name, address, IP address, URI, domain name etc. 2 AC holders can also be identified by a pointer to their PKC (its issuer and serial number), or a hash of their PKC, or a hash of their public key or, if the holder is a software object, a hash of itself. 3 Unfortunately X.509 did not standardise the term root CA or any term for the root of trust. Unfortunately disparate meanings for "root CA" have now evolved. supervisor issued by a manager, file access permissions issued by a file s owner. The whole data construct is digitally signed by the AA, thereby providing data integrity and authentication of the issuer. The attributes are embedded within the Attribute Certificate Information data construct (Figure 2). This contains details of the holder, the issuer, the algorithms used in creating the signature on the AC, the AC validity time and various optional extensions. Anyone familiar with the contents of an X.509 PKC will immediately see the similarities between it and an AC. In essence the public key of a PKC has been replaced by a set of attributes in an AC. (In this respect a public key certificate can be seen to be a specialisation of a more general attribute certificate.) Because the AC is digitally signed by the issuer, then any process in possession of an AC can check its integrity by checking the digital signature on the AC. Thus a PMI builds upon and complements existing PKIs. Since a PMI is to authorisation what a PKI is to authentication, there are many other similar concepts between PKIs and PMIs. Whilst public key certificates are used to maintain a strong binding between an entity s General Name 1 and its public key, an Attribute Certificate (AC) maintains a strong binding between the entity s General Name (or other David Chadwick (BSc, PhD) is Professor of Information Systems Security at the University of Kent, UK, and the leader of the Information Systems Security Research Group. He is a visiting professor at the University of Ljubljana, Slovenia, and a member of IEEE and ACM. He has published widely, with over 80 publications in international journals, conferences and workshops, including 3 books and 10 chapters in books. During the last 8 years he has been a principal researcher in 23 research projects. He is the originator of the PERMIS authorisation infrastructure, a standard s based Privilege Management Infrastructure (PMI) that is part of the US National Science Foundation s Middleware Initiative software release and is integrated with Globus Toolkit v3.3 onwards. He specialises in PKIs and PMIs, Trust Management and Internet and Grid Security research in general. He actively participates in standardisation activities; for instance he is the UK BSI representative to X.509 standards meetings. <d.w.chadwick@kent.ac.uk> Novática UPGRADE Vol. VI, No. 4, August

3 Figure 1: Attribute Certificate. Figure 2: Attribute Certificate Info. identifying information 2 ) and one or more privilege attributes. The authority that digitally signs a public key certificate is called a Certification Authority (CA), whilst the authority that signs an attribute certificate is called an Attribute Authority (AA). Within a PKI, each relying party must have one or more roots of trust. These are CAs who the relying party implicitly trusts to authenticate other entities. They are sometimes called root CAs 3 or trust anchors. Popular Web browsers come pre-configured with over 50 PKI roots of trust. The root of trust of a PMI is called the Source of Authority (SOA). This is an authority that a resource gatekeeper implicitly trusts to allocate privileges and access rights to it. The SOA is ultimately responsible for issuing ACs to trusted holders, and these can be either end users or subordinate AAs. Just as CAs may have subordinate CAs to which they delegate the powers of authentication and certification, similarly, SOAs may have subordinate AAs to which they delegate their powers of authorisation. For example, in an organisation the Finance Director might be the SOA for allocating the privilege of spending corporate money. But (s)he might also delegate this privilege to departmental managers (subordinate AAs) who can then allocate specific spending privileges (ACs) to project leaders. When a problem occurs in a PKI, a user might need to have his signing key revoked, and so a CA will issue a Certificate Revocation List (CRL) containing the list of PKCs no longer to be trusted. Similarly if a PMI user needs to have his authorisation permissions revoked, an AA will issue an Attribute Certificate Revocation List (ACRL) containing the list of ACs no longer to be trusted. The similarities between PKIs and PMIs are summarised in Table 1. 2 Elements Missing from the X.509(2001) PMI Specification 2.1 The Standard s Making Process In the standards creation process, experts endeavour to define what is needed in a particular standard, within the Concept PKI entity PMI entity Certificate Public Key Certificate (PKC) Attribute Certificate (AC) Certificate issuer Certification Authority (CA) Attribute Authority (AA) Certified entity Subject Holder Identifying information about the certified entity General Name General Name, PKC issuer and serial number, or hash of public key PKC or entity itself Certificate contents Subject s Public Key Holder s Privilege Attribute(s) Revocation List Certificate Revocation List (CRL) Attribute Certificate Revocation List (ACRL) Root of trust Root Certification Authority or Trust Anchor Source of Authority (SOA) Subordinate authority Subordinate Certification Authority Attribute Authority (AA) Table 1: A Comparison of PKIs and PMIs. 42 UPGRADE Vol. VI, No. 4, August 2005 Novática

4 constraints of the standards making process itself, which typically are: scope all standards necessarily have a carefully delimited scope, time this is often set to 4 years or less, available effort experts (or their employers) usually provide their input free of charge to the standard s committee, and so this necessarily constrains the amount of effort that is available, knowledge only the best knowledge available at the time of writing can be used, and this may be deficient; and finally the consensus building process this usually requires all the committee members to vote or comment on the (draft) standard at various stages, which necessarily leads to compromises being made, or multiple options being added to the standard. Once a (draft) standard is published, researchers and early adopters gain practical experience of building and using a standard, and it is at this stage that errors, inconsistencies and omissions are detected within the standard. These are then fed into the standard s committee as contributions to the next version of the standard. This is the case for virtually all IT standards, and the first version of the X.509 PMI standard is no exception. Some of the omissions were purposeful as they were never intended to be in the scope of the initial X.509 PMI standard, whilst others were omissions due to time or other constraints. 2.2 Sensible Software Engineering Early work by the author and his team implementing an X.509 (2001) PMI, found that X.509 PMIs are buildable, usable and work well, providing that sensible software engineering practices are adopted and the standard is not followed slavishly. Implementers must also be prepared to design any missing features themselves. The author s X.509 PMI implementation is called PERMIS [3][4] and this is now available as an open source version at < Sensible software engineering practices will ensure that extensibility, scalability and performance are built into the design, in order to cater for the evolving standard and user base. An example of not slavishly following the standard is as follows. In order to support Role Based Access Controls (RBAC) [20] in X.509, the standard defines two types of attribute certificate: role assignment ACs and role specification ACs. The former assign roles to subjects, the latter define the privileges granted to a role. In the PERMIS PMI implementation, role specification ACs are not utilised, but rather all the privileges of all the roles are grouped together in the target s access control policy, and this is read in by the Policy Decision Point (PDP) at initialisation time. This makes the authorisation decision process fast and efficient. On the other hand, Knight and Grandy in their research [5], found that by slavishly following the standard, and utilising both role assignment and role specification ACs, when a very simple PMI is implemented with just 4 role specification ACs and 3 role assignment ACs, along with associated PKCs, then 16 certificates need to be validated in order to make one access control decision. They report that in a reasonable organisation with 5 levels of delegation, and only 3 roles, the number of certificates that need to be validated for an access control decision rises to 110, leading to extremely poor performance. Delegation of authority allows a user (typically a manager or other group leader) to assign privileges to her subordinates as and when required. Modern organisations require this functionality in order to operate efficiently. Thus a PMI must have an efficient way of handling delegation of authority, and clearly this cannot be achieved by slavishly following the X.509 (2001) PMI model to produce long AC chains (for example from SOA to manager to team leader to staff member). This was also noted by the authors of RFC 3281 [6], which states: "Since the administration and processing associated with such AC chains is complex and the use of ACs in the Internet today is quite limited, this specification does NOT RECOMMEND the use of AC chains." However, delegation of authority is one feature which many users of PMIs require in their organisations, federations and virtual organisations. Thus the next version of X.509, to be published in late 2005 or 2006, provides one solution for making delegation of authority more efficient, through the definition of a delegation issuing service (see later). Another example of not slavishly following the standard is in the protocol used by AAs for storing ACs in directories, and used by applications for pulling ACs from directories for subsequent use by their PDPs. The X.509 standard expects system components to use the X.500 protocols for communicating between themselves e.g. the Directory Access Protocol (DAP) and Directory System Protocol (DSP). Very few products actually support DAP and DSP, instead preferring to support the Lightweight Directory Access Protocol (LDAP) [17][18]. Consequently we chose to use the LDAP protocol in PERMIS, but with some difficulty. Our difficulty arose because the LDAP standards have generally not supported X.509 ACs and PKCs very well. We encountered problems with the attribute name (some products used attributecertificate (wrong) and others attributecertificateattribute (correct), whilst some supported the ;binary extension (correct) and others did not (wrong)). We have had to keep changing our implementation as the LDAP products changed theirs. 2.3 Elements out of Scope The author found that several aspects of building a working PMI were not standardised in the first (2001) version of X.509 PMI because they were out of scope, and so the PERMIS team developed their own solutions to these problems. The most notable omission was the format and schema for the definition of the authorisation policy that is to be used by the target PDP. All PDPs need a policy to control them, as indicated in the ISO Access Control Framework standard [9]. When the author started work on PERMIS, no policy specification language was standardised or available. Consequently, the PERMIS team developed their own policy language in XML Novática UPGRADE Vol. VI, No. 4, August

5 (Extensible Markup Language) [7]. Subsequent to this, the OASIS (Object-Oriented Administrative Systems-development in Incremental Steps) consortium has defined its own authorisation policy language, termed XACML (Extensible Access Control Markup Language) [8]. Comprehensive as it is, XACML still has its own deficiencies, most notably, it does not support delegation of authority, which as already noted is a key feature that is supported by the X.509 PMI standard (and PERMIS). Consequently, it is not yet possible to convert PERMIS to use XACML policies. Once a policy has been specified, it needs to be securely stored somewhere. One can make the assumption that every system has a secure storage area and so the policy can be stored "as is" in that. We chose not to make such an assumption, since if the secure policy store is hacked, the entire system is then vulnerable. Consequently we decided to digitally sign our policies by their respective policy owners (SOAs) and store them, as attribute certificates, in the owners LDAP entries, from where they could be reliably retrieved by the PDPs. In our design, the AC issuer and holder names are the same, being that of the policy owner (SOA). In this model, one can see that such an AC is equivalent to a self signed root CA PKI certificate. This feature is now being standardised in the 2005 edition of the X.509 PMI (see later). Another feature not present in X.509 is any protocol or interface whereby the application dependent Policy Enforcement Point (PEP) can communicate with the application independent PDP. Several APIs have been published, most notably the Open Group s AZN specification [13], and the IETF s (Internet Engineering Task Force) Internet Draft Generic Authorization and Access control Application Program Interface [14], but both of these are based on the C programming language. Consequently the PERMIS team defined its own Java API, based on [13]. Subsequent to X.509 (2001) being published, OASIS did publish a protocol specification for PEP-PDP interactions, based on SAML [10]. The PERMIS team then implemented a profile of this [15][16]. More recently, OASIS has published a PDP interaction protocol based on XACMLv2 [11]. Another feature that is missing, that federations and Virtual Organizations (VOs) will need to agree amongst themselves, is the attributes that will be inserted into ACs. A common understanding is needed, since one domain will issue an AC containing an attribute, whilst another domain will use it to make access control decisions. Standard LDAP/ X.500 attributes could be used for at least a subset of these. The US academic community has spent considerable effort looking into this problem, and has defined the eduperson object class [12]. RFC 3281 has also partially filled this gap by defining the following attribute types: Service Authentication Information, Access Identity, Charging Identity, Group, Role and Clearance [6]. If organisations cannot agree on a standard set of attributes, which is certainly quite likely in the early stages of PMI use (as it was and still is in LDAP directory use) then a mechanism will be needed for attribute mapping between domains. Furthermore, a standard way of recognising the authority of remote PMI domains will be needed. Recognition of Authority in PMIs is the process that is analogous to cross certification in PKIs, whereby one CA decides to trust the PKCs issued by a remote CA. This feature is not currently part of the X.509 standard, but it is likely that work on this will start next year, and that it will be part of the 2009 edition of X.509. Finally, X.509 does not define any protocols for PMI and AC management. For PKI management, the IETF has defined the CMP standard [19]. A similar set of protocols will need defining for PMIs. In PERMIS we used a graphical user interface (GUI) for assigning ACs, and used LDAP for storing them in a directory, so we did not require any additional protocols. But once recognition of authority/cross certification is standardised, one or more new protocols may be required here. 3 New Features in X.509(2005) The new features in the X.509(2005) PMI standard can be broadly classified into two areas: additional attributes to support PMIs, and additional functionality to improve delegation of authority. Three new attribute types have been defined as described below: protected privilege policy attribute, XML privilege policy attribute and XML privilege information attribute. Two additional pieces of functionality have been added to the delegation of authority feature supported by X.509 PMIs. The first is the standardisation of a "no assertion" certificate extension, the second is the introduction of a delegation service. 3.1 Protected Privilege Policy attribute This functionality standardises the feature that has been used by PERMIS since its inception, i.e. that the PDP policy should be stored in a digitally signed AC so that it cannot be unknowingly tampered with. The protected privilege policy attribute type has the same syntax as an attribute certificate, but its content is a privilege policy attribute rather than a privilege attribute. X.509 also standardises two attributes to hold the privilege policy. One (the XML privilege policy attribute) is used to hold policies encoded in XML syntax, the other (the privilege policy attribute) is used to store a policy in any syntax, along with an identifier of the syntax (see below). The privilege policy attribute was actually defined in the first (2001) PMI version of X XML Privilege Policy Attribute (and Privilege Policy Attribute) These attributes can be used to hold the privilege policies that will used by PDPs. The XML privilege policy attribute is used to hold policies encoded in XML syntax, whilst the privilege policy attribute is used to store a policy in any syntax, along with a globally unique object identifier that identifies the syntax. 3.3 XML Privilege Information Attribute The XML privilege information attribute is used to store a privilege, in XML format, in an X.509 AC. The XML 44 UPGRADE Vol. VI, No. 4, August 2005 Novática

6 privilege attribute values will need to be self identifying, and will usually be governed by an appropriate XML schema or DTD. 3.4 The "no assertion" Feature In some situations it is recognised that a privilege holder (an AA) may be allowed to delegate the held privileges to a subordinate, but may not be allowed to assert the privileges herself. An examples might be an airline manager who assigns privileges to pilots to fly particular aircraft, but is not allowed to fly the aircraft herself. A delegation service (see later) is another example. We can prevent the holder of these privileges from asserting them by placing a "no assertion" extension into the AC issued to it. This extension will inform all relying parties that understand it, that the AC holder is not allowed to assert the privileges contained within this AC. This extension obviously needs to be a critical extension, since any relying party that does not understand it, must refuse to accept the AC, rather than simply ignoring the extension and allowing the privileges to be asserted. 3.5 Delegation Service A delegation service is designed to issue ACs on behalf of other AAs. The delegation service concept recognizes that in some organizational contexts, it might be preferable for a manager (an AA) who wishes to delegate authority to a subordinate, be not empowered to issue the X.509 AC herself, but rather should request a delegation service to issue the AC on her behalf. The benefits of using a Delegation Issuing Service (DIS) instead of AAs issuing X.509 ACs themselves are several. Firstly, the DIS can support a fully secure audit trail and database, so that there is an easily accessible record of every AC that has been issued and revoked throughout the entire organization. If each manager were allowed to independently issue their own ACs, then this information would be distributed throughout the organization, making it difficult or impossible to collect, being possibly badly or never recorded or even lost. Secondly, the DIS can be provided with the organization s delegation policy, and apply control procedures to ensure that a manager does not overstep her authority by issuing greater privileges to subordinates, or even to herself, than the organization s policy allows. Thirdly, the manager does not need to hold and maintain her own private signing key, which would be needed if the manager were to issue and sign her own ACs. Only the DIS needs to have an AC signing key. This could be a very important feature in organizations that use mechanisms other than PKIs for authentication such as user names and passwords, or Kerberos etc. Finally, if the DIS is given its own AC by the SOA, it can replace the (set of) manager s AC(s) in the AC validation chain and therefore decrease the complexity of AC chain validation. The AC chain length would always be two when the DIS issues the ACs to end entities, whereas it would be of arbitrary length when the managers issue the ACs themselves. This, coupled with the abolition of role specification ACs (as in PERMIS), virtually eliminates the performance penalty noted in [5] and reported earlier. Finally, less CRLs will need to be issued only the DIS will need to issue a CRL rather than each manager. This will further simplify AC chain validation. We have recently implemented the delegation issuing service in PERMIS [21]. Two new certificate extensions have been defined to support the DIS service. The first, "issued on behalf of", informs the relying party that this AC, although issued and signed by the DIS, was actually issued on behalf of the AA pointed to in this extension. The second, "indirect issuer", is placed in the AC or PKC of the DIS, and informs the relying party that the DIS has the full authority of the SOA to issue ACs on behalf of other AAs. This is needed in cases where the DIS does not have the full set of privileges in its own AC that it is delegating to someone else. Without this extension or a full set of privileges, any AA could issue an AC containing any privilege at all, and simply point, via the "issued on behalf of" extension, to an AA that does have the full set of privileges. Clearly this cannot be allowed. For a much fuller discussion of the delegation issuing service, see [21]. Although X.509(2005) has defined a delegation service, and has provided certificate extensions to support the service, there are still some features of the service that have not been standardised. For example, when an AA wishes to use the services of a DIS to issue an AC on its behalf, it needs to contact the DIS to request the certificate to be issued. How this communication is achieved is outside the scope of X.509, and more properly lies within the scope of the IETF or OASIS. In the PERMIS implementation we have implemented a Java API and a web services SOAP protocol. 4. Conclusions This paper has presented an overview of Privilege Management, as specified in the X.509 (2001) standard. We have also provided some of the results of our practical implementation experience and shown that the standard is valid, viable and useful, although a significant number of PMI components were not standardised when we started our research. Since then, a number of other standards committees, such as OASIS and the IETF, have provided standards for some of these missing components. Nevertheless, there are still a number of PMI components that remain to be standardised, and we have indicated where the ITU-T is likely to continue its X.509 PMI standardisation effort in the coming years. References [1] C. Adams, S. Lloyd. "Understanding Public-Key Infrastructure: Concepts, Standards, and Deployment Considerations". Macmillan Technical Publishing, [2] R. Housley, T. Polk. "Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure". John Wiley and Son, ISBN: , 2001 [3] D.W.Chadwick, A. Otenko "The PERMIS X.509 Role Based Privilege Management Infrastructure". Future Novática UPGRADE Vol. VI, No. 4, August

7 Generation Computer Systems, 936 (2002) 1 13, December Elsevier Science BV. [4] D.W.Chadwick, A. Otenko, E.Ball. "Role-based access control with X.509 attribute certificates", IEEE Internet Computing, March-April 2003, pp [5] S. Knight, C. Grandy. "Scalability Issues in PMI Delegation". Pre-Proceedings of the First Annual PKI Workshop, Gaithersburg, USA, April 2002, pp [6] S. Farrell, R. Housley. "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002 [7] D.W.Chadwick, A. Otenko. "RBAC Policies in XML for X.509 Based Privilege Management" in Security in the Information Society: Visions and Perspectives: IFIP TC11 17 th Int. Conf. On Information Security (SEC2002), May 7-9, 2002, Cairo, Egypt. Ed. by M. A. Ghonaimy, M. T. El- Hadidi, H.K.Aslan, Kluwer Academic Publishers, pp [8] "OASIS extensible Access Control Markup Language (XACML)" v1.0, 12 Dec 2002, disponible en < [9] ITU-T Rec X.812 (1995) ISO/IEC :1996 "Security Frameworks for open systems: Access control framework". [10] OASIS. "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) v1.1". 2 September Ver < [11] "OASIS extensible Access Control Markup Language (XACML)" v2.0, 6 Dec 2004, disponible en < php? wg_abbrev=xacml>. [12] Internet2 Middleware Architecture Committee "EduPerson Specification". Ver < [13] The Open Group. "Authorization (AZN) API", January 2000, ISBN [14] T. Ryutov, C. Neuman, L. Pearlman. "Generic Authorization and Access control Application Program Interface C-bindings", <draft-ietf-cat-gaa-cbind-05.txt>, Nov Ver < [15] Von Welch, Frank Siebenlist, David Chadwick, Sam Meder, Laura Pearlman. "Use of SAML for OGSA Authorization", Feb Disponible en < gridforum. org/projects/ogsa-authz>. [16] 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, September [17] W. Yeong, T. Howes, S. Kille. "Lightweight Directory Access Protocol". RFC1777, March [18] M. Wahl, T. Howes, S. Kille. "Lightweight Directory Access Protocol (v3)", RFC 2251, Dec [19] C. Adams, S. Farrell. "Internet X.509 Public Key Infrastructure Certificate Management Protocols," RFC 2510, March [20] David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn And Ramaswamy Chandramouli. "Proposed NIST Standard for Role-Based Access Control". ACM Transactions on Information and System Security, Vol. 4, No. 3, August 2001, pp [21] D.W.Chadwick. "Delegation Issuing Service" presented at NIST 4 th Annual PKI Workshop, Gaithersberg, USA, April [22] ISO /ITU-T Rec. X.509 (2001) The Directory: Public-key and attribute certificate frameworks. 46 UPGRADE Vol. VI, No. 4, August 2005 Novática