Books - Non-fiction

Web Services Security Kerberos Binding

of 25
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Web Services Security Kerberos Binding December 2003 Authors Giovanni Della-Libera, Microsoft Brendan Dixon, Microsoft Praerit Garg, Microsoft Maryann Hondo, IBM Chris Kaler, Microsoft Hiroshi Maruyama,
Web Services Security Kerberos Binding December 2003 Authors Giovanni Della-Libera, Microsoft Brendan Dixon, Microsoft Praerit Garg, Microsoft Maryann Hondo, IBM Chris Kaler, Microsoft Hiroshi Maruyama, IBM Anthony Nadalin, IBM Nataraj Nagaratnam, IBM Copyright Notice (c) 2003 IBM Corporation, Microsoft Corporation. All rights reserved. IBM and Microsoft (collectively, the Authors ) hereby grant you permission to copy and display the Web Services Security Kerberos Binding Specification, in any medium without fee or royalty, provided that you include the following on ALL copies of the Web Services Security Kerberos Binding Specification, or portions thereof, that you make: 1. A link or URL to the Specification at this location 2. The copyright notice as shown in the Web Services Security Kerberos Binding Specification. EXCEPT FOR THE COPYRIGHT LICENSE GRANTED ABOVE, THE AUTHORS DO NOT GRANT, EITHER EXPRESSLY OR IMPLIEDLY, A LICENSE TO ANY INTELLECTUAL PROPERTY, INCLUDING PATENTS, THEY OWN OR CONTROL. THE Web Services Security Kerberos Binding SPECIFICATION IS PROVIDED AS IS, AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE Web Services Security Kerberos Binding SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE Web Services Security Kerberos Binding SPECIFICATION. The Web Services Security Kerberos Binding Specification may change before final release and you are cautioned against relying on the content of this specification. The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the Web Services Security Kerberos Binding Specification will at all times remain with the Authors. No other rights are granted by implication, estoppel or otherwise. Abstract This document describes how to use Web Services security specifications with Kerberos. Status This Web Services Security Kerberos Binding Specification is an initial public draft release and is provided for review and evaluation only. IBM and Microsoft hope to solicit your contributions and suggestions in the near future. IBM and Microsoft make no warrantees or representations regarding the specifications in any manner whatsoever. Table of Contents 1. Introduction 1.1. Notational Conventions 1.2. Namespaces 1.3. Schema File 2. Web Service Security Usage 2.1. Security Tokens 2.2. Policies 2.3. Signing and Encrypting 3. GSS-API for Kerberos Interoperability 3.1. Acquiring a Credentials Handle 3.2. Establishing a Security Context 3.3. Signing with XML Signature 3.4. Replay Prevention 3.5. Encryption with XML Encryption 4. General Kerberos Interoperability 4.1. Kerberos Security Token 4.2. Using XML Signature 4.3. Using XML Encryption 4.4. PKI Interoperability PKI Kerberos Kerberos PKI 5. Derived Keys 6. Security Considerations 7. Acknowledgements 8. References 1. Introduction Kerberos is an established authentication and security infrastructure in use in many environments today. Consequently, as applications integrate with and are developed for Web services, there is a need to leverage existing security infrastructure. This specification describes how to integrate Kerberos security environments with the Web service security architecture. Integration with Web services security requires the following aspects: Requesting and issuing security tokens Attaching security token to messages Establishing a secure context Signing and encrypting the message using the security context This specification describes two models of Web service usage and interoperability: GSS-API and Raw Kerberos Notational Conventions The keywords MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , MAY , and OPTIONAL in this document are to be interpreted as described in RFC When describing abstract data models, this specification uses the notational convention used by the XML Infoset [7]. Specifically, abstract property names always appear in square brackets (e.g., [some property]). When describing concrete XML schemas, this specification uses the notational convention of WS-Security [13]. Specifically, each member of an element s [children] or [attributes] property is described using an XPath-like notation (e.g., The use of {any} indicates the presence of an element wildcard ( xs:any/ ). The use indicates the presence of an attribute wildcard ( xs:anyattribute/ ) Namespaces The following namespaces are used in this document: Prefix Namespace S S11 ds xenc wsse wsu wsk This specification uses the SOAP 1.2 specification for its examples; however, the mechanisms defined here are also applicable to SOAP Schema File The schema for this specification can be located at: 2. Web Service Security Usage This specification builds on the WS-Security [WS-Security], WS-Trust [WS-Trust], and WS-SecureConversation [WS-SecureConversation] specifications to integrate Kerberos functionality. The following sub-sections describe basic usage patterns that are common to both Kerberos scenarios defined in this specification Security Tokens The security tokens used by both models are binary and not based on XML. Consequently, the wsse:binarysecuritytoken element from WS-Security is used to pass security tokens inside SOAP messages. The wsse:valuetype and wsse:encodingtype attributes describe the security token s type and encoding. Applications integrating Kerberos with WS-Security MUST include their tokens as instances of wsse:binarysecuritytoken . They SHOULD encode these in base64 (i.e., wsse:encodingtype= wsse:base64binary ). Each of the models describes the valid security token formats and how these tokens are obtained Policies Every security infrastructure has configuration and runtime options. For example, some allow mutual authentication and others allow negotiating the cryptographic algorithms and key properties. Interoperation requires all parties selecting compatible options, if not identical. Applications SHOULD note the options they expect in their policy which SHOULD be expressed using WS-Policy and WS- SecurityPolicy. Each model definition describes its specific algorithms for establishing mutual policies Signing and Encrypting The Web services security model uses the mechanisms described in WS-Security to sign and encrypt messages. Both mechanisms use URIs to indicate the type of signature or encryption. XML Signature [XML Signature] enables multiple signatures, over potentially different parts of the message, and includes a number of pre-defined signature algorithms (e.g. XML Signatures apply indirectly to the signed content: That is, the signature is formed over the digest of the describing element (the ds:signedinfo sub-element of the ds:signature element) rather than over the content directly. The ds:signedinfo element contains, among other details, the content s digest and an expression of the signature algorithm (using the ds:signaturemethod element). XML Encryption [XML Encryption], and its use by WS-Security, carries the encrypted content within an xenc:encrypteddata element, wholly replacing the encrypted element. Among the children of the xenc:encrypteddata element is xenc:encryptionmethod , which expresses what encryption algorithm the application used. Each application and security infrastructure must define the acceptable algorithms, security context, and keys. The exact algorithms for signing and encrypting vary between the different Kerberos models and are described in detail in those sections of this specification. Within this context, the mechanisms described in WS-Security represent the authenticator that is used to secure messages. That is, typical Kerberos authenticators are not used verbatim. Instead, those aspects are included in the message and are referenced as part of a signature. For this reason it is STRONGLY RECOMMENDED that both message timestamps and nonces be included in signatures and that message freshness checks be applied. Refer to the security considerations section of the WS-Security specification for additional information. As well, it is RECOMMENDED by this specification that signatures be used instead of encryptions that include digests. 3. GSS-API for Kerberos Interoperability GSS-API presents a common approach and feature set over a number of different and popular security protocols. It is frequently used when two Web services, both existing within Kerberos environments leveraging GSS-API, want to securely interoperate across the Internet. The GSS-API model revolves around a security context a set of state shared between a client (created by GSS_Init_sec_context) and server (accepted by GSS_Accept_sec_context). The context carries attributes such as replay detection elements, sequencing elements, and shared session keys. GSS-API includes this context on top of the underlying protocol used. For example, when using X.509 Certificates, GSS-API adds sequencing facilities and a session-level symmetric key. GSS-API abstracts existing protocols and adds additional features. It should be noted that there are two approaches for GSS-API integration: a Web services security mechanism or layering Web services security on top of existing mechanisms. This specification is agnostic of approach as it defines the wire protocol and the primary difference between the two approaches is the API calls and sequencing Acquiring a Credentials Handle GSS-API designates the abstracted security protocols as mechanisms. When an application first acquires its credentials handle, which scopes all of its operations within GSS-API, it specifies either a specific mechanism type (i.e. mech_type) or NULL to request the default system mechanism. Since GSS-API shields an application from the vagaries of the different underlying protocols, applications are free to select their mechanism type (or use the default). WS-Security adds no new requirements since it can carry GSS-API security tokens as binary tokens. However, the sender and receiver must be in agreement as to the type and contents of the security token Establishing a Security Context GSS-API requires the exchange of at least one, and perhaps multiple, messages to establish the shared context. When requiring an application-level exchange, GSS_Init_sec_context or GSS_Accept_sec_context returns with either GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. The context does not exist until GSS_S_COMPLETE is returned. Applications perform this message exchange using the mechanisms described in WS- Trust for handling challenge/responses and WS-SecureConversation for requesting a security context token. Essentially, a binary negotiation occurs using the SPNEGO blobs resulting in a Security Context Token (SCT) which is associated with the SPNEGO results. This means that the SCT can be used to indicate the context (and keys) to the recipient. Specifically, the object returned from GSS-API MUST be attached using a wsse:binarynegotiation element inside of the wsse:requestsecuritytoken and wsse:requestsecuritytokenresponse elements containing the GSS-API object. The ValueType attribute indicates the type of negotiation. It is RECOMMENDED that the ValueType attribute use wsk:spnego. In this scenario, the wsse:binarynegotiation element is specified along with the security context token request element wsse:tokentype equal to wsse:securitycontexttoken inside of the wsse:requestsecuritytoken element. It is STRONGLY RECOMMENDED that the wsse:binarynegotiation element be signed (or in the case that signatures cannot be initially applied that it be signed as soon as possible). While the exact format of the binary object is not relevant to this process, it is specific to the type specific on the wsse:binarynegotiation element. Negotiations of type wsk:spnego MUST conform to RFC The result is that the security context token issued is bound to the GSS-API context negotiated. This binding is implicit, but in some scenarios, the issuer MAY include information in the issued security context token which it uses on subsequent messages to correlate the contexts. This is done by including a wsk:correlation element in the wsse:securitycontexttoken . The contents of this element MUST be preserved verbatim and MUST be passed in all uses of the token. The syntax overview is as follows: wsse:securitycontexttoken wsk:correlation Target= /wsk:correlation /wsse:securitycontexttoken /wsse:securitycontexttoken/wsk:correlation This element is used to pass correlation information which MUST be returned verbatim. Note that multiple correlation elements MAY be present. This optional attribute allows a specific SOAP actor/role to be identified with the correlation element. /wsse:securitycontexttoken/wsk:correlation/{any} The contents of this element are up to the creator and are not interpreted by anyone except the sender. This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the element. Applications MUST NOT sign or encrypt content using GSS-API until the mechanism is ready. Normally, that is not until shared context establishment. However, some mechanisms may support signing and encryption before fully establishing the context. These indicate readiness by returning true for the prot_ready_state boolean from GSS_Init_sec_context or GSS_Accept_sec_context. It is RECOMMENDED that mutual authentication through GSS-API (i.e. mutual_req_flag is true) be requested although applications MAY choose not to do so. The figure below illustrates the model for GSS-API interoperation with the Web service security specifications: 1. A client service (App1) obtains a TGT to allow it to later obtain tickets for services. This can be done using the traditional Keberos mechanisms or using the mechanisms described in WS-Trust. 2. A client service (App1) obtains an ST for another service (App2). This can be done using the traditional Kerberos mechanisms or using the mechanisms described in WS-Trust. 3. The client uses the mechanisms described in WS-Trust to initialize the GSS- API context: The client service issues a RequestSecurityToken message to the target service. As well, a BinaryNegotiation is included to encapsulate the GSS API initialization context. The service MAY respond with a RequestSecurityTokenResponse message. The client MAY respond with a RequestSecurityTokenResponse message. Steps (b) and (c) continue until both sides are happy (and/or one fails). On success, the SecurityContextToken is returned. Note that steps (b) and (c) MAY be omitted. The following sample message illustrates creating a security context based on a SPNEGO exchange between two parties. In this example, one round trip is required for SPNEGO. ?xml version= 1.0 encoding= utf-8 ? S:Envelope xmlns:s= S:Header wsse:security xmlns:wsse= ds:signature xmlns:ds= !-- Signature over the request - /ds:signature /wsse:security /S:Header S:Body wsu:id= body wsse:requestsecuritytoken xmlns:wsse= xmlns:wsk= wsse:tokentype wsse:securitycontexttoken /wsse:tokentype wsse:binarynegotiation ValueType= wsk:SPNEGO Encoding= wsse:Base64Binary jhkajkhkjhd /wsse:binarynegotiation /wsse:requestsecuritytoken /S:Body /S:Envelope The following is a sample response for the scenario described above: ?xml version= 1.0 encoding= utf-8 ? S:Envelope xmlns:s= S:Header wsse:security xmlns:wsse= xmlns:wsk= wsse:securitycontexttoken wsu:id= sct wsu:identifier wsk:correlation wsu:identifier uuid: /wsu:identifier /wsk:correlation /wsse:securitycontexttoken ds:signature xmlns:ds= !-- Signature over the response - /ds:signature /wsse:security /S:Header S:Body wsu:id= body wsse:requestsecuritytokenresponse xmlns:wsse= xmlns:wsu= xmlns:wsk= wsse:tokentype wsse:securitycontexttoken /wsse:tokentype wsse:binarynegotiation ValueType= wsk:SPNEGO Encoding= wsse:Base64Binary HorueHNUEE /wsse:binarynegotiation wsse:requestedsecuritytoken wsse:securitycontexttoken wsee:reference URI= #sct / /wsse:securitycontexttoken /wsse:requestedsecuritytoken /wsse:requestsecuritytokenresponse /S:Body /S:Envelope The figure below illustrates an alternate model which MAY also be used. In this case steps (1) and (2) are the same as above except that the communication is not with the target service, but instead with a broker (such as a KDC). For this scenario, the RequestSecurityToken message MUST include an wsp:appliesto scoping element indicating the target service (App2). This allows the broker to know the intended target. This is critical because the SecurityContextToken returned MUST include the session key encrypted for the target (App2). The client can then communicate with the target (App2) using the security context token and the mechanisms in WS-Security and this document to secure the message Signing with XML Signature GSS-API supplies two methods for creating and verifying signatures: GSS_GetMIC and GSS_VerifyMIC. These operate within the context the client and target service pair. For example, they utilize any session keys established and include, when requested, sequencing components that prevent replay attacks. Applications MAY use the GSS-API signature methods within the framework XML Signature describes. However, a new signature algorithm is required for GSS-API: When establishing the GSS-API shared context, the application MUST include an XML Signature ds:keyinfo containing a wsse:securitytokenreference identifying the security context token that was established (as described in WS- SecureConversation). The application MUST use the GSS-API methods to generate and verify the digital signatures when the above algorithm is specified. Specifically, an application uses GSS-API to create an XML Signature as follows: 1. Compute the digest over the reference data as specified in XML Signature. 2. Specify the digest algorithm used to hash the referenced data as the ds:digestmethod . 3. Build the ds:signedinfo block, expressing the GSS-API signature algorithm as the ds:signaturemethod . 4. Canonicalize the ds:signedinfo block as defined in XML Signature. 5. Apply GSS_GetMIC output to the canonical form of the ds:signedinfo block, generating an octet sequence. 6. Optionally (but RECOMMENDED) include a ds:keyinfo containing a wsse:securitytokenreference identifying the security context associated with the GSS-API context. Note that there MAY be a wsse:securitytokenreference element (Step 6) with a reference to the security context for the associated GSS-API context key. If a key isn't specified explicitly, and a context is associated with the message, the key from the context SHOULD be used. The following sample message illustrates the use of this algorithm in conjunction with WS-Security. ?xml version= 1.0 encoding= utf-8 ? S:Envelope xmlns:s= S
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks