|
以文本方式查看主题 - W3CHINA.ORG讨论区 - 语义网·描述逻辑·本体·RDF·OWL (http://bbs.xml.org.cn/index.asp) -- 『 Web Services & Semantic Web Services 』 (http://bbs.xml.org.cn/list.asp?boardid=10) ---- Secure and Flexible Certificate Access in WSSecurity (http://bbs.xml.org.cn/dispbbs.asp?boardid=10&rootid=&id=41802) |
|
-- 作者：flanker721 -- 发布时间：12/30/2006 5:32:00 PM -- Secure and Flexible Certificate Access in WSSecurity Secure and Flexible Certificate Access in WSSecurity As an integral part of the Web Services Security (WS-Securithrough LDAP Component Matching Sang Seok Lim IBM Watson Research Center P.O. Box 218 Yorktown Heights, NY 10598 slim@us.ibm.com Jong Hyuk Choi IBM Watson Research Center P.O. Box 218 Yorktown Heights, NY 10598 jongchoi@us.ibm.com Kurt D. Zeilenga IBM Linux Technology Center Redwood City, CA 94105 zeilenga@us.ibm.com ABSTRACT ty), directory services are used to store and access X.509 cer- ti¯cates. Lightweight Directory Access Protocol (LDAP) is the predominant directory access protocol for the Internet, and hence for the Web services. Values of LDAP attribute and assertion value syntaxes, though de¯ned using ASN.1, are encoded in simple octet string formats which generally do not preserve the complete structure of the abstract val- ues. As a result, LDAP matching rules for certi¯cates need to be provided in a certi¯cate-syntax speci¯c way, while X.500 matching rules can be constructed from structured ASN.1 syntax de¯nition. Moreover, LDAP has traditionally lacked the capability to make assertions against components of values of complex syntaxes such as X.509 certi¯cates. The WS-Security needs to be able to locate a target X.509 cer- ti¯cate by matching against arbitrary certi¯cate components in its security token references. Therefore, WS-Security re- quires the directory server to be prepared with all the possi- ble matching functions for maximum °exibility. This is very cumbersome due to the lack of ASN.1 awareness in LDAP server implementations. This led to development of reme- dies such as the recently proposed Certi¯cate Parsing Server (XPS). XPS extracts relevant components of the certi¯cate and stores them in separate and searchable attributes. Due to the signi¯cant downside of these remedies, we decided to seek after an ASN.1 based Component Matching alterna- tive in an attempt to make an LDAP directory server ASN.1 aware. With Component Matching and ASN.1 awareness, LDAP can provide WS-Security with various matching rules °exibly. In this paper, we describe our implementation of the Component Matching and ASN.1 awareness in OpenL- DAP Software. This paper will also describe the use of the Component Matching technology in various security com- ponents of Web Services, especially in the context of WS- Security and XKMS. The experimental results show that °exible and secure certi¯cate access can be accomplished ACM Workshop on Secure Web Services, October 29,2004, Fairfax VA, USA. Copyright 2004 ACM 158113973X/ 04/0010....$5.00. without sacri¯cing performance and manageability. Categories and Subject Descriptors H.3.5 [Information Storage and Retrieval]: Online In- formation Services-Web-based services; C.5.5 [Computer System Implementation]: Metrics|Servers General Terms Security, Design Keywords PKI, X.509 Certi¯cate, Certi¯cate Repository, Component Matching, LDAP 1. INTRODUCTION Public Key Infrastructure (PKI) [6] is an integral part of the WS-Security speci¯cation [17] which provides an application- layer security framework for Web services by including se- curity information in SOAP (Simple Object Access Pro- tocol) [1] messages. Portions of a SOAP message can be signed in order to ensure integrity and can be encrypted to ensure con¯dentiality. Certi¯cate Authority (CA) provides the most universal form of the Security Token Service to both Web service providers and requesters. The use of PKI ensures the authenticity of the security tokens themselves. The public key of a Web services entity is used to validate the integrity and authenticity of SOAP messages which were established by the corresponding private key and to encrypt the contents of the SOAP messages. X.509 certi¯cates [4] are often managed in the directory and are accessed through standard directory access proto- cols such as X.500 [11] Directory Access Protocol (DAP) [7] and Lightweight Directory Access Protocol (LDAP) [5]. In order to embed an X.509 certi¯cate as a security token in a SOAP message, a Web service requester needs to retrieve the X.509 certi¯cate from a CA. Alternatively, if the Web service requester includes a certi¯cate URI as a reference to the security token, it is a Web service provider who retrieves the certi¯cate from the CA. Even when the certi¯cate is embedded in the SOAP message, the Web service providers may need to contact the certi¯cate repository in order to verify whether the certi¯cate has been revoked by retrieving a Certi¯cate Revocation List (CRL). LDAP is predominantly being used as the directory access protocol for the Internet. Compared to X.500 Directory 87 Access Protocol, LDAP renders lightweight directory service by providing string-based encodings of names and attribute values (hence of assertion values), simple protocol encoding, direct mapping onto TCP/IP, and the reduced number of operations. However, these simpli¯cations come at a price: LDAP generally does not preserve the complete structure of abstract values and the protocol and its implementations are unable to harness the full power of the underlying ASN.1 data de¯nitions. Due to the use of specialized string-based encodings for each syntax, adding support for new syntaxes and matching rules requires new development e®orts. DAP avoids these problems by the use of ASN.1 (Abstract Syntax Notation One) [9] encoding rules, in particular the Basic Encoding Rules [8]. Though these limitations were not viewed as a signi¯cant problem during LDAP's early years, it is clear that a num- ber of directory applications, such as PKI, are signi¯cantly hampered by these limitations. For instance, in PKI, a cer- ti¯cate needs to be located based upon the contents of its components, such as serialNumber, issuer, key identi¯ers, and subjectAltName [10]. LDAP search operations do not understand the ASN.1 type of the certi¯cate attribute and the assertion as de¯ned in [10], because attributes and asser- tions in LDAP are encoded in an octet string with syntax speci¯c encoding rules. Not only would it require excep- tional e®ort to support matching rules such as certi¯cateM- atch and certi¯cateExactMatch as de¯ned in [10], that e®ort would have to be repeated for each matching rule introduced to match on a particular component (or set of components) of a certi¯cate. Because of the amount of e®ort each server vendor must undertake to support each new rule, few new rules have been introduced to LDAP since inception. Ap- plications had to make due with existing rules. Foreseeing the need to be able to add new syntaxes and matching rules without requiring recoding of server imple- mentations, the directory community engineered a number of extensions to LDAP to address these limitations. The Generic String Encoding Rules (GSER) [14] was introduced and is now used in describing and implementing new LDAP string encodings. GSER produces human readable UTF- 8 [22] encoded Unicode [19] character strings and supports reuse of existing LDAP string encodings. The Component Matching [15] mechanism was also introduced to allow LDAP matching rules to be de¯ned in terms of ASN.1. Imple- mentations may use automated systems to (statically and dynamically) value parsing and matching functions. Addi- tionally, Component Matching also introduces rules which allow arbitrary assertions to be matched against selected component values of complex data types such as certi¯cates. For example, the Component Matching enables matching against the selected components of a certi¯cate without the need to de¯ne a speci¯c matching rule or requiring custom codes to implement that matching rules for the certi¯cate attributes. Though the directory community saw GSER and Compo- nent Matching as an eloquent solution to LDAP syntax and matching rule limitations, there was some concerns, as most LDAP server implementations were not ASN.1 aware, that its adoption would be slow. To ful¯ll immediate needs of PKI applications, another solution based upon component extraction (or \data de-aggregation") was proposed and im- plemented in Certi¯cate Parsing Server (XPS) [2]. While some viewed this as being more pragmatic, as it shifted sig- ni¯cant complexity from the server to the client and intro- duced a number of security and management issues, it is con- sidered by many to be not a workable solution for PKI appli- cations (and certainly not a workable general solution to the component matching problem). In the spring of 2004, IBM undertook an engineering e®ort to provide ASN.1 awareness, GSER, and component matching support in the OpenLDAP Project's Standalone LDAP Daemon (slapd) (the directory server component of OpenLDAP Software). We started from implementing ASN.1 awareness in the server by providing an automatic path to generate encoders and decoders for BER, DER [8], and GSER from given ASN.1 data type de¯ni- tions. In addition, this ASN.1 infrastructure automatically generates the component extraction and matching routines for the individual components of an attribute type. The search ¯lter functions were modi¯ed to support Component- Filter, ComponentAssertion, and ComponentReference. As a result, it becomes possible to support complex matching such as X.509 certi¯cateMatch with a Certi¯cateAssertion syntax without manually de¯ning syntax speci¯c encodings and matching routines. We show an example of the °exible reference method with an extension to <ds:X509Data> named, GenericCerti¯cateRef- erence which is designed after the certi¯cateMatch of the X.509 recommendation. De¯ning GenericCerti¯cateRefer- ence was easy because the Component Matching infrastruc- ture could automatically generate the corresponding certi¯- cateMatch matching rules from the ASN.1 type speci¯ca- tion. Web services can also use Component Matching in a URI reference of Security Token Reference by specifying the componentFilterMatch matching rule as the extended matching rule in the LDAP URI. Component Matching pro- vides XKMS with the interfaces to PKI, allowing it to lo- cate and validate a certi¯cate °exibly. With the Component Matching enabled LDAP server as the security token service, the speci¯cation of token references will become very °ex- ible. The Component Matching also ¯lls the security gap in the certi¯cate access which required special Directory In- formation Tree (DIT) structuring to avoid. The Component Matching and GSER facilitate the °exible and extensive use of security token references in SOAP messages. This paper is organized as follows. Section 2 introduces WS-Security and its use of X.509 certi¯cates as security to- kens. Section3 presents an example X.509Data extension element and how Component Matching technology is used for XKMS. Section 4 introduces GSER and the Component Matching. In Section 5, we present the design of the GSER and Component Matching support in the OpenLDAP di- rectory server. Section 6 shows experimental results of our prototype implementation of LDAP component matching in slapd. Section 7 concludes the paper. 2. WEB SERVICES SECURITY 2.1 SOAP and WSSecurity SOAP (Simple Object Access Protocol) is a protocol for invoking methods on servers, services, components, and ob- jects [1]. It is a way to create widely distributed, complex computing environments using an existing Internet infras- 88 01 <?xml version=”1.0” encoding=”utf-8”?> 02 <S:Envelope xmlns:S=http://www.w3.org/2001/12/soap-envelope> 03 <S:Header> 04 <wsse:Security> 05 <wsse:SecurityTokenReference wsu: Id=“#X509Token 06 <wsse:Reference 07 URI=“ldap://ldap.example.com/dc=example, dc=ibm???(userCertificate:componentFilterMatch:= 08 and:{ item:{ component “tbsCertificate.serialNumber”, rule allComponentsMatch, value 9453771 }, 09 item:{ component “tbsCertificate.extensions.1.KeyUsage.value”, rule bitStringMatch, value ‘01000000’B }}”)> 10 </wsse:SecurityTokenReference> 11 <ds:Signature> 12 <ds:SignedInfo> 13 <ds:CanonicalizationMethod 14 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 15 <ds:SignatureMethod 16 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 17 </ds:SignedInfo> 18 <ds:SignatureValue> 19 Hp1ZkmFZ/2kQLXDJbchm5gK.. 20 </ds:SignatureValue> 21 <ds:KeyInfo> 22 <wsse:SecurityTokenReference> 23 <wsse:Reference URI="#X509Token"/> 24 </wsse:SecurityTokenReference> 25 </ds:KeyInfo> 26 </ds:Signature> 27 </wsse:Security> 28 </S:Header> 29 <S:Body> 30 <m:GetLastTradePriceResponse xmlns:m=”http://example.com”> 31 <Price>34.5</Price> 32 </m:GetLastTradePriceResponse> 33 </S:Body> 34 </S:Envelope> Figure 1: Web Service Request and Response with Security Token Reference. tructure, enabling Web service developers to build Web ser- vices by linking heterogeneous components over the Internet. For interoperability over heterogeneous platforms, it is built on top of XML and HTTP which are universally supported in most services. WS-Security [17] is recently published as the standard for secure Web Services. It provides a set of mechanisms to help Web Services exchange secure SOAP messages. WS- Security provides a general purpose mechanism for signing and encrypting parts of SOAP messages for authenticity and con¯dentiality. It also provides a mechanism to associate se- curity tokens with the SOAP messages to be secured. The security token can be cryptographically endorsed by a se- curity authority. It can be either embedded in the SOAP message or acquired externally. 2.2 LDAPPKI in WSSecurity In WS-Security, a security token can be either embodied in a SOAP message or acquired from an external service by following SecurityTokenReference [17]. Signed security to- kens such as X.509 certi¯cates are accessed through di®er- ent forms of references de¯ned in the WS-Security standard and in various security token pro¯les [18]. The security to- kens can be retrieved and registered with the existing access methods. Either standard access protocols such as LDAP and HTTP or an ad-hoc access mechanism can be used to ac- cess security tokens. XKMS (XML Key Management Spec- i¯cation) [20] also provides a Web Service client which lacks direct access to the security tokens with an o²oading mech- anism. X.509 certi¯cates are the most universal form of the security tokens which is well proven in the heterogeneous and distributed network, the Internet. X.509 certi¯cates were originally designed to be stored in directories. Hence, directory access protocols such as X.500 and LDAP are the most appropriate way to access them in terms of the naming and information models and its powerful search capabilities. In the following example scenario which illustrates an op- erational °ow of accessing security tokens for a SOAP mes- sage shown in Figure 1, it is assumed that the Web service provider needs to contact the Security Token Service in or- der to fetch and verify its security token. The °ow is as follows: 1. The service requester constructs a SOAP message. It contains a signature for the key elements of the mes- sage. <ds:signature> is placed in the Security Header block (lines 03 - 28 in Figure 1). In this scenario, a X.509 certi¯cate is located in the external Security Token Service. The reference to the external token or the certi¯cate is included in the message within <SecurityTokenReference> elements (line 05 - 10). The constructed message is sent to the Web Service. 2. TheWeb Service fetches KeyInfo in line 21-25. It refer- ences X.509Token, or ID which is de¯ned in line 05-10 as SecurityTokenReference. In this case, the reference is an LDAP URI in line 07 - 09. In the URI, there is a component ¯lter in which \tbsCerti¯cate.issuer" and \tbsCerti¯cate.extensions.1.keyUsage.value" refer to the corresponding components of a certi¯cate and 9453771 and \'01000000'B" are assertion values against the components. More detailed explanation of the component ¯lter will be described in Section 5.2.1. 89 <wsse:SecurityTokenReference> <wsse:KeyIdentifier EncodingType=“…#GSER” ValueType=“…#GenericCertificateFields” { serialNumber 9453771, issuer {type cn, value ray} , keyUsage ‘100000000’B } <wsse:KeyIdentifier> </wsse:SecurityTokenReference> CertificateAssertion ::= SEQUENCE { serialNumber [0] CertificateSerialNumber OPTIONAL, issuer [1] Name OPTIONAL, subjectKeyIdentifier [2] SubjectKeyIdentifier OPTIONAL, authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL, certificateValid [4] Time OPTIONAL, privateKeyValid [5] GeneralizedTime OPTIONAL, subjectPublicKeyAlgID [6] OBJECT IDENTIFIER OPTIONAL, keyUsage [7] KeyUsage OPTIONAL, subjectAltName [8] AltNameType OPTIONAL, policy [9] CertPolicySet OPTIONAL, pathToName [10] Name OPTIONAL, subject [11] Name OPTIONAL, nameConstraints [12] NameConstraintsSyntax OPTIONAL } <wsse:SecurityTokenReference> <ext:KeyIdentifier EncodingType=“…#XER” ValueType=“…#GenericCertificateFields” <CertificateAssertion> <serialNumber>9453771</serialNumber> <issuer>cn=ray</issuer> <keyUsage>Signature</keyUsage> </CertificateAssertion> <wsse:KeyIdentifier> </wsse:SecurityTokenReference> (b) XER (c) GSER (a) CertificateAssertion XML Schema Figure 2: Certi¯cate Assertion Schema De¯nition and GenericCerti¯cateReference XER and GSER. 3. The Security Token Service searches for the certi¯- cate according to the LDAP URI from the Web ser- vice provider and returns the resulting certi¯cate as a search result. 4. TheWeb service provider validates the <ds:Signature> in the <wsse:Security> header and processes the SOAP message to return the service result to the Web service requester. In the above scenario, the Web service retrieves the secu- rity token stored in a directory through LDAP as a security token access method. In order to retrieve the certi¯cate, the Web service will send an LDAP request correspond- ing to the reference URI. The Security Token References can have various forms of references in addition to LDAP URI. In case of X.509 certi¯cates, they can be referenced by X509IssuerSerial, X509SubjectName, and X509SKI. The <ds:X509Data> element of the <ds:KeyInfo> can also be extended to represent elements from external namespaces. 2.3 LDAP Deficiencies for Certificate Access Although WS-Security needs to be able to locate a certi¯- cate by matching against arbitrary components of a certi¯- cate, LDAP does not easily provide an universal matching mechanism to the X.509 certi¯cate. In LDAP, attribute and assertion values are represented in octet string. No struc- tural information is stored along with them. A brute force way to provide matching for complex attributes is to pro- vide syntax speci¯c matching rules. For a X509IssuerSerial reference for example, it is possible to write a special match- ing function which matches the certi¯cate attribute against the assertion value consisting only of issuer name and serial number. Obviously, it will be too costly to de¯ne syntax speci¯c matching rules for all possible references. In or- der for an LDAP server to support X509SubjectName and X509SKI, matching rules speci¯c to the references need to be implemented. For a very °exible reference such as Cer- ti¯cateMatch as de¯ned in X.509 recommendation [10], it would be very di±cult to provide the corresponding match- ing rule in LDAP. Moreover, it would be di±cult to cope with changes such as certi¯cate extensions. To address this mismatch between X.509 certi¯cate and LDAP, the attribute extraction mechanism was recently pro- posed in the Certi¯cate Parsing Server (XPS) designed by the University of Salford [3]. In XPS, all the certi¯cate attributes are extracted and stored as simple and search- able LDAP attributes and matching is performed on the ex- tracted attributes. Although it facilitates matching against components of a complex attribute, it can be considered as a suboptimal approach due to the following respects. First, matching is performed on the extracted attributes but not on the certi¯cate itself. Because the contents of the ex- tracted attributes are mutable, there is a chance of return- ing wrong certi¯cates to Web services. It is strongly recom- mended for Web services to verify the returned certi¯cate again. In order to minimize the security hole, the server ad- ministrator must ensure the integrity of a certi¯cate and ex- tracted attributes. Second, when there is more than one cer- ti¯cate in a directory entry, one per key usage for example, the Web services may be returned with multiple certi¯cates even though they searched for certi¯cates having a speci¯c key usage. The matched values control [10] does not solve the problem, because matching is not performed on the cer- ti¯cate itself. It is inevitable to restrict the Directory Infor- mation Tree (DIT) structure in designing a certi¯cate DIT to avoid an additional searching step in the Web services [2]. Third, the XPS does not facilitate matching against a com- plex assertion value as in X.500 directory. It is not possible to perform a °exible matching as in X.509 certi¯cateMatch without making the LDAP directory server ASN.1 aware. 3. COMPONENT MATCHING In order to overcome the mismatch between LDAP and the requirement of °exible certi¯cate matching imposed by ad- vanced applications like Web Services, we decided to pro- vide 1) ASN.1-awareness and 2) Component Matching ca- pabilities to an LDAP directory server. With the ASN.1- awareness support for the LDAP server, ASN.1 values are manifested within the server. It will be possible to use an ASN.1 value in an assertion. Hence, matching can be per- formed in an abstract level according to the corresponding ASN.1 type de¯nition. With Component Matching, it be- comes possible to match an assertion value against speci¯c 90 Certificate / CRL Repository (LDAP) Registration Authority (RA) Certificate Authority (CA) XKMS Trust Service Client Tier 0 RetrievalMethod Tier 1 / 2 Locate / Validate Key Mgmt Certificate / CRL Access Publish Certificate Publish Certificate / CRL Management Transactions Management Transactions Registration Revocation Recovery Figure 3: XKMS in PKI. components of a complex attribute. For example, an infras- tructure is provided to perform matching on an arbitrary component of an X.509 certi¯cate, such as serialNumber, issuer, keyUsage, and subjectAltName. Compared to the XPS approach, our approach of providing ASN.1 awareness and Component Matching has the follow- ing advantages: 1. It does not store the X.509 attributes separate from the certi¯cate itself. Therefore, it does not increase storage requirements and does not open a potential to the compromised integrity between a certi¯cate and its extracted attributes. 2. Matching is performed directly on the contents of the certi¯cate but not on the associated attribute's con- tents. Even if there is more than one certi¯cate in a user's entry, it can return only the matched certi¯cate when it is used with the matched values control [10]. 3. Flexible matching becomes possible because match- ing between an attribute value and an assertion value, both represented in ASN.1, will be provided. 3.1 Component Matching and Security Token Reference In the X.509 token pro¯le [18] of WS-Security, it is de¯ned that the following three types of token references can be used: 1. Reference to a Subject Key Identi¯er: the value of a certi¯cate's X.509SubjectKeyIdenti¯er. 2. Reference to a Security Token: either an internal or an external URI reference. 3. Reference to an Issuer and Serial Number: the certi¯- cate issuer and serial number. Because it is de¯ned to be extensible, any security token can also be used with appropriate schemas. It is shown in Fig- ure 1 that the <ds:X509Data> element of <ds:KeyInfo> is used as the security token. <ds:X509Data> de¯ned in [21] contains various references such as X509IssuerSerial, X509SubjectName, X509SKI, and so on. With the ASN.1 awareness and the Component Matching support in an Open LDAP directory server, these references can be used with- out the need of implementing syntax speci¯c matching rules for various types of the references. It is also possible to use elements from external namespace in <ds:X509Data> for further °exibility. Figure 2 shows one such an example. Here, the GenericCerti¯cateReference element from dsext namespace is used to provide a generic reference mecha- nism which implements Certi¯cateMatch in the X.509 rec- ommendation [10]. The reference consists of a sequence of certi¯cate attributes, serialNumber, issuer, subjectKeyIden- ti¯er, authorityKeyIdenti¯er, certi¯cateValid, privateKey- Valid, subjectPublicKeyAlgID, keyUsage, subjectAltName, policy, pathToName shown in Figure 2 (a), each of which is de¯ned optional. By using the example reference, it would be possible to resolve a security key reference in a very °ex- ible way. For instance, searching for a certi¯cate having a subjectAltName with a speci¯c keyUsage becomes possible. Figure 2 (b) shows that the reference is encoded in XML while Figure 2 (c) shows that the reference is encoded in GSER. With the ASN.1 aware and Component Matching enabled LDAP server, the °exible reference format for an X.509 cer- ti¯cate can now be de¯ned in ASN.1 with con¯guring the LDAP server to understand the reference. The required matching rules, encoders, and decoders for the reference type will be automatically generated and integrated to the LDAP server. This improvement in °exibility will foster the °exible use of security token references in the Web Services by making it easy to create and update references. 3.2 Component Matching and XKMS Figure 3 illustrates a general PKI architecture which is com- prised of CA, RA, and two types of end-entities. When a PKI is used for Web Services, there are two types of PKI clients: one directly accesses PKI; the other indirectly ac- cesses it by using service proxies such as XML Key Man- agement Speci¯cation (XKMS) [20] services which provide clients with a well de¯ned interface to a PKI so as to hide the complexities of the underlying PKI. The XML Key Infor- mation Service Speci¯cation (X-KISS) is one of the services provided by XKMS [20]. It de¯nes two key services: locate and validate. In the following sections, it will be presented how the Component Matching can be used in the X-KISS services with respect to certi¯cates and CRLs access. 3.2.1 Certificate Access Figure 4 shows an example X-KISS locate service request. In the request, there is <QueryKeyBinding> which describes how to bind this request to a desired public key. In the example, <KeyUsage> and <ds:KeyInfo> are provided to bind the request. A client using the XKMS service sends the X-KISS Locate request shown in Figure 4. In response to the request, the XKMS service needs to resolve the request and then might contact an LDAP directory server to locate the desired certi¯cate. In the example locate request, the serial number in line 15-17 and the key usage in line 07 are supplied by the client for <QueryKeyBinding>. With Com- ponent Matching, the component ¯lter will be constructed 91 00 <?xml version="1.0" encoding="utf-8"?> 01 <LocateRequest xmlns:ds=http://www.w3.org/2000/09/xmldsig# 02 xmlns:xenc=http://www.w3.org/2001/04/xmlenc# 03 Id="I8fc9f97052a34073312b22a69b3843b6“ 04 Service=http://test.xmltrustcenter.org/XKMS 05 xmlns="http://www.w3.org/2002/03/xkms#"> 06 <QueryKeyBinding> 07 <KeyUsage>Signature</KeyUsage> 08 <ds:KeyInfo> 09 <wsse:SecurityTokenReference> 10 <ds:X509Data> 11 <ds:X509IssuerSerial> 12 <ds:X509IssuerName> 13 o=IBM,c=US 14 </ds:X509IssuerName> 15 <ds:X509SerialNumber> 16 9453771 17 </ds:X509SerialNumber> 18 </ds:X509IssuerSerial> 19 </ds:X509Data> 20 </wsse:SecurityTokenReference> 21 </ds:KeyInfo> 22 </QueryKeyBinding> 23 </LocateRequest> Figure 4: Example XKMS Locate Service Request. from the request by the XKMS services as shown in Figure 5. The component reference \tbsCerti¯cate.extension.*" refers to all extensions of the certi¯cate of which KeyUsage is one extension. In the value, \extndID 15" is the object identi¯er of a KeyUsage and \'100000000'B" is used to check if a cer- tain bit(the ¯rst bit for signature) is set. The corresponding component ¯lter of Figure 5 enables the XKMS service to ¯nd a certi¯cate of an issuer for a signature purpose only. If the client uses GenericCerti¯cateReference explained in the previous section and the Component Matching is supported in an LDAP directory server, the XKMS service can use ar- bitrary ¯elds of a certi¯cate in order to construct component ¯lters to process the locate request. 3.2.2 CRL Access The XKMS service also provides an X-KISS Validate Ser- vice with which a client using XKMS services can check the status of a public key by sending some of <ds:KeyInfo> el- ements in <QueryKeyBinding> in line 08-21 of Figure 4. For instance, if it checks the validity of a X.509 certi¯cate using CRLs, the client may send <X509Data> containing <ds:X509SerialNumber> 9453771 </X509SerialNumber> in <QueryKeyBinding>. In response to the request, the XKMS service might choose to use either CRL based validation or Online Certi¯cate Status Protocol (OCSP) [16]. A certi¯cate revocation list (CRL) [6] can be generated and distributed periodically by the CA, making it available on the Internet by typically using an LDAP directory server or aWeb server. Because a CRL contains the list of multiple re- voked certi¯cates, it can become quite large and burdensome to transmit it over the Internet. To alleviate this problems, OCSP was proposed to provide a timelier and more e±cient status mechanism. The XKMS service can speak to OCSP responders which can check the status of a certi¯cate. The OCSP responder returns the status (either good, revoked, or unknown) of a requested certi¯cate. With OCSP, the XKMS service does not need to download and scan the CRL, which are burdensome to the service. We conceive that Component Matching can be used as an (userCertificate:componentFilterMatch := and:{ item:{ component “tbsCertificate.serialNumber”, rule IntegerMatch, value 9453771 }, item:{ component “tbsCertificate.extension.*”, rule allComponentsMatch, value {extnID 15, extnValue ‘100000000’B} } } ) Figure 5: Example Component Filter. alternative to OCSP. The CRL is a sequence of pairs of a revoked certi¯cate's serial number and a revoked time [6]. In order to check the status of a certi¯cate, the XKMS ser- vice needs to construct a component assertion by using the serial number of the certi¯cate as shown in the upper item of Figure 5 and send it to the LDAP directory server. Then the server will perform Component Matching on the CRL against the assertion to ¯nd the asserted certi¯cate in the CRL. By using the Component Matching based CRL vali- dation, the whole CRLs is not required to be downloaded to the XKMS service. An LDAP server already has been widely used for distributing certi¯cates and CRLs. Hence, if the server can perform validity checking over LDAP as well, it will be a very practical and e±cient alternative to the OCSP which needs additional protocol layer, or and an OCSP responder. 4. COMPONENT MATCHING AND GSER The attribute syntaxes of X.500 are de¯ned in ASN.1 types. Basically, the types are constructed structurally from basic types to composite types. Every ¯eld of an ASN.1 type is a component. Component Matching [15] de¯nes how to refer to a component within an attribute value by retrieving the structural information of an ASN.1 type and how to match the component against an assertion value. Matching rules are de¯ned for the ASN.1 basic and composite types. It also de¯nes a new assertion and ¯lter targeted for a component. These de¯nitions are based on ASN.1 so that they can be applied to any syntax, as long as the syntaxes are speci¯ed in ASN.1. A native LDAP encoding does not represent the structure of an ASN.1 type. Instead, it is represented either in octet string or in binary. With the LDAP encoding, as a result, it is di±cult to contain the structural information of ASN.1 type in its representation. In order to solve this problem, Legg [14] recently proposed GSER (Generic String Encod- ing Rules). Component matching uses GSER as its basic encoding for the component ¯lter. GSER generates a hu- man readable UTF-8 character string encoding of a given ASN.1 speci¯cation. It de¯nes UTF8 string encodings at the lowest level of primitive ASN.1 types such as INTE- GER, BOOLEAN, and STRING types and then it builds up more complex ASN.1 types such as SEQUENCE and SET from the lowest level. Thus, the structural information of an ASN.1 speci¯cation is maintained in encodings so that it can be recovered in the decoding process. By using GSER to store attribute values instead of the native LDAP string encoding, LDAP server will become capable of identifying 92 { version 2, serialNumber 12345 , signature { algorithm 1.2.840.113549.1.14, parameters NULL}, issuer {{type cn, value IBM trust} , {type o, value IBM},{type c, value US}}, validity {notBefore {2004 01 13 18 59}, notAfter {2005 01 13 18 59} }, … } GSER encodings TBSCertificate :: = SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublickKeyInfo subjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIOMAL subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL extensions [3] EXPLICIT Extensions OPTIONAL } typedef struct TBSCerticate{ AsnInt version; AsnInt serialNumber; struct AlgorithmIdentifier* signature; struct Name* issuer; … } C internal data structure Encoding EncTBSCertificate(…) Decoding DecTBSCertificate(…) ASN.1 Compiling Figure 6: ASN.1 TBSCerti¯cate speci¯cation, its compiler output, and example GSER encodings. the structure of ASN.1 speci¯cation of the attribute types. Furthermore, a component ¯lter of an LDAP request is also encoded in GSER. Hence, GSER is an essential mechanism to ASN.1 awareness and Component Matching. GSER en- coding can also be used in an assertion to facilitate a very °exible and abstract matching of two ASN.1 values. Figure 6 shows the ASN.1 type speci¯cation of TBSCerti¯- cate and its GSER encodings. TBSCerti¯cate is de¯ned as SEQUENCE so that there are curly braces at the beginning and at the end of its GSER encodings. It has version, se- rialNumber etc. as its components inside of SEQUENCE. Within the braces in the encoding, there is version and 2, or its value, followed by a comma which separates the encod- ing of the subsequent ¯eld. GSER de¯nes each basic type's encoding and then combines them structurally to more com- plex ones by using \f", \," and \g". On the other hand, a native LDAP encoding does not have any uniform rule to construct the structural information of attribute value in it. 5. COMPONENTMATCHINGIMPLEMENTATION IN OPENLDAP An ASN.1 compiler translates ASN.1 modules into C data structures representing ASN.1 and their encoding / decod- ing routines as illustrated in Figure 7. We extended the eS- NACC ASN.1 compiler to implement the GSER backend in addition to the originally supported BER and DER [12]. It also generates component equality matching rules and com- ponent extract functions which will be discussed in the rest of the section in detail. In order to facilitate the integration of the newly de¯ned syntaxes without the need of rebuild- ing the slapd executable, the generated data structures and routines are built into a module which can be dynamically loaded to slapd. The rest of the section will provide a detailed description of the component matching in two steps. After describing how to make the OpenLDAP directory server ASN.1 aware, the description of component ¯lter processing, aliasing, and ASN.1 types GS/B/DER decoder Component equality matching rule Component extract function OpenLDAP Server (slapd) Dynamic Module Load C Data structures Automatic generation eSNACC Compiler GSER back-end Figure 7: Input and Output of an eSNACC Com- piler. component indexing will be presented. Then, the overall operational °ow of Component Matching will be described. 5.1 ASN.1 Awareness 5.1.1 eSNACC Compiler We have implemented a GSER backend for the extended eSNACC compiler. GSER can be used as an LDAP en- codings for newly de¯ned attribute types. With GSER, string-based LDAP encodings can maintain the structures of their corresponding ASN.1 types. The assertion values in the component ¯lter are also represented in GSER and the GSER decoders are used to decode them into their in- ternal representations. Figure 6 shows the example C data structure for a TBSCerti¯cate ASN.1 type and its corre- sponding GSER encodings. Generated C data structure for the ASN.1 type has data ¯elds corresponding to components of the ASN.1 type. Once the C data structure for TBSCer- ti¯cate is instantiated, it can be converted into GSER en- codings by EncTBSCerti¯cate() and the encodings can be decoded into the C data structure by DecTBSCerti¯cate(). The eSNACC compiler also generates matching rules and extract functions automatically which will be further dis- cussed in the next subsection. 93 Table 1: Attribute Aliasing Table. Alias Attribute Aliased Attribute Component Reference Matching Rule x509certi¯cateSerialNumber userCerti¯cate tbsCerti¯cate.serialNumber integerMatch x509certi¯cateIssuer userCerti¯cate tbsCerti¯cate.issuer distinguishedNameMatch 5.1.2 Component Representation of ASN.1 Types A new data structure of slapd is needed to represent an attribute value at its component level because the original data structure for attributes does not contain the structure information of an ASN.1 type in its representation. Every ¯eld of an ASN.1 type is a component which is addressable by a component reference. In our implementation, the com- ponent data structure consists of two parts: one to store the value of the component; the other to store a component descriptor which contains information on how to encode, de- code, and match the value of the component. The data structure of a component appears as a tree which keeps the structural information of the original ASN.1 spec- i¯cation using nodes and arcs. Each component node of the tree not only has data values but also represents the structural information of the given ASN.1 speci¯cation by having links to subordinate nodes. In the tree, any node can be referenced by a component reference in order to per- form matching on the corresponding component. Hence, we need a function to traverse the tree and locate the refer- enced node. The ASN.1 compiler also generates component extractor routines for this purpose. 5.1.3 Syntax and Matching Rules An attribute is described by an attribute type in LDAP. An attribute type contains two key ¯elds which help to de¯ne the attribute as well as rules that it must follow. The ¯rst ¯eld is a syntax which de¯nes the data format used by the attribute type. The second ¯eld is a matching rule which is used by an LDAP server to compare an attribute value with an assertion value supplied by the LDAP search or compare operations. Attributes must include the matching rules in their de¯nition. At least, an equality matching rule should be supported for each attribute type. From the viewpoint of an LDAP server, an ASN.1 speci¯cation de¯ning a new at- tribute type requires a new syntax and its matching rule to be de¯ned in it. To fully automate the component match- ing in which the composite attribute types are de¯ned in ASN.1, we extended the eSNACC compiler to generate the basic equality matching rule of a given ASN.1 type, or all- ComponentMatch matching rule speci¯ed in RFC 3687 [15]. The allComponentMatch matching rule evaluates to true only when the value of the referenced component of the attribute and that of ComponentAssertion are the same. It can be implemented by performing matching from the top-most component which is identi¯ed by the component reference recursively down to the subordinate components. The generated matching function of each component can be overridden by other matching functions through a matching rule re¯nement table. Therefore, it is possible that a syn- tax developer can replace the compiler-generated matching functions with existing matching functions of slapd which might be more desirable. In order to support this re¯ning mechanism, slapd checks if a matching function is overrid- den or not by looking up the re¯nement table, whenever it (userCertificate:componentFilterMatch := not:item:{ component “tbsCertificate.serialNumber”, rule IntegerMatch, value 9453771 } ) Component Reference Component Assertion Component Filter New Matching Rule Figure 8: Example Component Filter. is executed. 5.2 Component Matching 5.2.1 Component Assertion and Filter RFC 3687 [14] de¯nes a new component ¯lter as the means of referencing a component of a composite attribute and as the means of representing an assertion value for a composite attribute types. Component assertion is an assertion about the presence or the values of components within an ASN.1 value. In the component assertion, there are three key ¯elds: ² Component Reference: speci¯es which component of an attribute value will be matched against an assertion value. ² Matching Rule: speci¯es which matching rule will be used to perform matching on the values. ² Value: An assertion value in GSER. Component ¯lter is an expression of component assertions, which evaluates to either TRUE, FALSE, or Unde¯ned af- ter performing matching. Figure 8 illustrates an exam- ple component ¯lter. The component reference \Certi¯- cate.serialNumber" identi¯es one component in the Certi¯- cate attribute value. In the component reference, \." means identifying one of components subordinate to the preceding component. In the component assertion, rule is followed by an integerMatch matching rule [11] which will be used to compare the following assertion value with the referenced component of the attribute value. The routines required to support the component ¯lter and the component assertion were hand-coded while the routines for the component asser- tion values are automatically generated from a given ASN.1 type. 5.2.2 Attribute / Matching Rule Aliasing To enable component matching, clients as well as servers need to support GSER and new component matching rules. However, the client side changes will be minimal, if at all, be- cause the component ¯lter can be speci¯ed by using the ex- isting extensible matching rule mechanism of LDAPv3 and the component assertion value is represented as the text centric GSER encoding rules. In particular, the clients that 94 Table 2: Decoder Performance Comparison. d2i X509() ASN.1 ASN.1 Decoder Decoder for CM Time (usec) 32.74 40.20 72.00 accept search ¯lters as strings require no changes to utilize component matching other than ¯lling in the necessary com- ponent ¯lter as the search ¯lter. However, for those clients who have search ¯lters hard coded in them, we propose an attribute aliasing mechanism which maps a virtual attribute type to an attribute component and a component matching rule, and a matching rule aliasing mechanism which maps a virtual matching rule to a component assertion. Attribute aliasing registers a set of virtual attributes to an LDAP server. The virtual attributes themselves ¯nd corre- sponding matching rules and component references by look- ing up an attribute alias table. The example attribute alias table is shown in Table 1. x509certi¯cateSerialNumber at- tribute is aliased to userCerti¯cate.tbsCerti¯cate.serialNumb er with the integerMatch matching rule. Hence, the ¯lter (x509certi¯cateSerialNumber=12345) is considered equiva- lent to (userCerti¯cate:ComponentFilter:=item:component tbsCerti¯cate.serialNumber, rule integerMatch, value 12345). With an attribute aliasing, clients only have to form sim- ple assertions to utilize component matching. A matching rule alias works in a similar way. An alias matching rule is mapped into the corresponding a component reference and a matching rule. 5.2.3 Putting It All Together The overall °ow of acquiring security tokens in Web services with Component Matching is as follows. First, the ASN.1 speci¯cation of a X.509 certi¯cate is compiled and the gen- erated routines are loaded into the LDAP server. Once they are loaded successfully, Component Matching on the certi¯- cate can be performed in the server. Then, the Web Service requester sends the Web Service provider a SOAP message which contains SecurityTokenReference. URI reference was taken as an example in the following discussion. The Web service provider fetches the SecurityTokenReference from the message and performs an LDAP search based on the LDAP URI in it. The search ¯lter can contain the compo- nent assertion against the corresponding component of the certi¯cate. Accepting a component search request, certi¯- cates in the LDAP server are decoded by the corresponding DER decoder to construct a component tree of the certi¯- cate. It has all certi¯cate attributes as de¯ned in the X.509 recommendation. The incoming component ¯lter is parsed to obtain the component assertion value and the component reference by the GSER decoder for the ¯lter. The compo- nent extractor extracts the referenced component from the component tree which is speci¯ed by the component refer- ence in the component ¯lter. The component assertion value is decoded by the corresponding GSER decoder for the ex- tracted component. At this point, we have obtained the ASN.1 internal representation of both the component asser- tion value and the returned certi¯cate component. Matching is performed on these two internal data structures and the matched certi¯cate is returned to theWeb Service provider. 6. PERFORMANCE CONSIDERATIONS The benchmarking was performed with a 40,000 entry DIT. Using an LDAP benchmark in ruby scripts [13], only read operation was performed ¯rst on the entries with varying base DNs in the LDAP search requests. The read bench- mark was made to test how fast data could be read from slapd. The machine running slapd has two 2.40GHz Hy- perthreading Intel Xeon CPUs and 1.5Gbytes memory. The slapd was con¯gured with a BDB backend. First, we mea- sured the performance of eSNACC compiler generated DER decoders as compared to that of the openssl decoder, d2i X509() function (manually written certi¯cate parsing function). Ta- ble 2 shows how much time both decoders took to decode an example X.509 certi¯cate generated by openssl. d2i X509 took 32.74 usec to decode a certi¯cate. The com- piler generated DER decoder took 40.20 usec in case of not allocating component descriptors which is not out side of the pure decoding process. The compiler generated decoder took 7.46 usec longer as compared to d2i X509(). It is be- cause the decoder allocated memory not only for ASN.1 val- ues but also for the component data structures of each ¯elds of the certi¯cate. We also integrated the compiler generated decoders into slapd and performed searching by Component Matching. We measured the average time to search for an entry con- taining the target certi¯cate, varying the number of concur- rent clients. The search scope is base and a component ¯lter, \(userCerti¯cate:componentFilterMatch:=item:component \tbsCerti¯cate.serialNumber", rule integerMatch, value 945 3771)" is used in the search. As the number of concurrent clients is increased from 1 to 8, the overall searching time of both cases were also increased from 1 msec to 6 msec approximately. When the number of concurrent clients is 1, Component Matching (CM) takes 1.2 msec and d2i X509 takes 1.18 msec. When the number of concurrent client be- come 8, CM takes 5.91 msec and d2i X509 takes 6 msec. The time di®erence between the Component Matching and d2i X509 is very small and can be considered to be within the experimental error bound. It is because the decoding itself is only small portion of a search operation. It only accounts for 4-7% of overall search time. We also performed subtree search and it appeared that the average searching time of CM was only slightly higher than that of d2i X509. The overheads of parsing component ¯lters can be removed by using attribute and matching rules aliases. Overall searching time is heavily dependent on other factors such as ¯lter parsing, indexing, and caching rather than de- coding. By the experiment, It was proven that a °exible and secure way of accessing a certi¯cate and CRL was achieved without performance degradation. The maintenance of proper indices is critical to the search performance in the Component Matching as much as in the conventional attribute matching. In slapd, the attribute in- dexing is performed by generating a hash key value of the attribute syntax, matching rule, and the attribute value and maintains the list of IDs of those entries having the matching value in the set of attribute values of the indexed attribute. The component indexing can be speci¯ed in the same way as the attribute indexing, except that the component ref- 95 erence is used to specify which component of a composite attribute to be indexed. If the referenced component is a basic ASN.1 type, the indexing procedure will be the same as the attribute indexing. The indices for the referenced component are accessed through a hashed value of the cor- responding syntax, matching rule, and value in the index ¯le for the referenced component of the composite attribute. In OpenLDAP, the indexing of the composite component is centered on the GSER encodings of the component value. The hash key of a component value is generated from its GSER encodings together with its syntax and matching rule. For the SET and SET OF constructed types, it is required to canonicalize the order of the elements in the GSER en- codings before generating the hashed key value. For <all> component reference of SET OF and SEQUENCE OF. it is needed to union the indices for each value element of SET OF and SEQUENCE OF. 7. CONCLUSION WS-Security is a key protocol for securing SOAP message exchanges. It de¯nes token references in order to acquire se- curity tokens internally and externally. An X.509 certi¯cate is an universally used security token and is usually stored and retrieved via LDAP. The X.509 certi¯cate pro¯le of WS- Security and XML Signature standards provides a rich set of reference methods for the X.509 certi¯cate in a °exible and extensible way. Component Matching and ASN.1 awareness in LDAP are very e®ective mechanisms to cope with this °exibility and extensibility. This paper presented the design of the Component Match- ing in the OpenLDAP directory server in the context of WS-Security. It is described the ¯rst implementation of the component matching and ASN.1 awareness in a pure LDAP based directory server. In order to provide a fully auto- mated infrastructure, we extended an ASN.1 compiler to automatically generate the component extraction / match- ing routines and encoders / decoders of BER, DER, and GSER for a given ASN.1 type. To make the server un- derstand an incoming ComponentFilter in GSER format, the search ¯lter processing was modi¯ed to support Compo- nentFilter, ComponentAssertion, and ComponentReference as well. For backward compatibility in the case where the search ¯lters are hard coded to client applications, we also provide an alias mechanism for the attribute names and the matching rules. According to the experiments, the perfor- mance of the prototype system which integrated compiler- generated decoders was proven to be competitive to that of the hand-optimized ones. We conclude from the experiment that °exible and secure certi¯cate access can be achieved without losing performance and manageability. 8. REFERENCES [1] D. Box and D. Ehne. Simple object access protocol (SOAP). W3C Note, May 2000. [2] D. W. Chadwick. De¯ciencies in LDAP when used to support PKI. Comm. of the ACM, 46(3), March 2003. [3] D. W. Chadwick, E. Ball, and M. Sahalayev. Modifying LDAP to support x.509-based PKIs. In 17th Annual IFIP WG 11.3 Working Conference on Database and Applications Security, August 2003. [4] W. Ford and D. Solo. Internet x.509 public key infrastructure certi¯cate and certi¯cate revocation list (CRL) pro¯le. RFC 3280, 2002. [5] J. Hodges, R. Morgan, and M. Wahl. Lightweight directory access protocol (v3): Technical speci¯cation. RFC 3377, September 2002. [6] R. Housley, W. Ford, W. Polk, and D. Solo. Internet X.509 public key infrastructure certi¯cate and CRL pro¯le. RFC 2459, January 1999. [7] ITU-T Rec. X.511, The directory: Abstract service de¯nition, 1993. [8] ITU-T Rec. X.690, ASN.1 encoding rules: Speci¯cation of basic encoding rules (BER), canonical encoding rules (CER), and distinguished encoding rules (DER), 1994. [9] ITU-T Rec. X.680, Abstract syntax notation one (ASN.1): Speci¯cation of basic notation, December 1997. [10] ITU-T Rec. X.509, The directory: Public-key and attribute certi¯cate frameworks, March 2000. [11] ITU-T Rec. X.500, The directory: Overview of concepts, models and service, February 2001. [12] R. Joop. Snacc 1.2rj. http://www.fokus.gmd.de/ovma/freeware/snacc/ entry.html. [13] A. Krennmair and R. Lischka. Testing OpenLDAP server, March 2004. [14] S. Legg. Generic string encoding rules. RFC 3641, October 2003. [15] S. Legg. X.500 and LDAP component matching rules. RFC 3687, February 2004. [16] M. Myers, R.Ankney, A.Malpani, and C.Adams. Internet X.509 public key infrastructure online certi¯cate status protocol - OCSP. RFC 2560, June 1999. [17] OASIS. Web services security: SOAP message security 1.0 (WS-Security 2004). OASIS Standard 200401, March 2004. [18] OASIS. Web services security: X.509 certi¯cate token pro¯le. OASIS Standard 200401, January 2004. [19] The Unicode Consortium. The Unicode Standard, Version 4.0. Addison-Wesley, Boston, 2003. [20] W3C. XML key management speci¯cation (XKMS). W3C Standard, March 2001. [21] W3C. XML - signature syntax and processing. W3C Standard, February 2002. [22] F. Yergeau. UTF-8, a transformation format of ISO 10646. RFC 3629, November 2003. 96
|
|
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
156.250ms |