- From: Magnus Nyström <magnus@rsa.com>
- Date: Tue, 18 Nov 2008 15:00:00 +0100 (W. Europe Standard Time)
- To: public-xmlsec@w3.org
This is in response to ACTION-105 that I got last week. Essentially it is a slight adaptation of my earlier post on this topic, http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0064.html -- Magnus -- X. Derived Keys X.1 Use Cases and Background Several open specifications make use of derived keys, e.g. RSA Laboratories' PKCS #5 v2.0 [Link] and OASIS' WS-SecureConversation Version 1.3 [Link]. These derived keys are used for a variety of purposes including encryption and message authentication, and the purpose of key derivation itself is typically a combination of a desire to expand a given, but limited, set of key material and prudent security practices of limiting use (exposure) of such key material. Contrary to the situation in the ASN.1-based world (e.g. S/MIME [LINK]), there is currently a lack of general support in the core XML Security specifications, XML Signature and XML Encryption, for derived keys. Amendment 1 of the aforementioned PKCS #5 v2.0 Amendment 1 [Link] adds support for derived keys only in the context of password-based cryptography. Other XML-based open specifications have similar limitations (see below). This means that an originator of an XML document or message cannot generally make use of key derivation in a standardized manner when performing cryptographic operations on that document. X.2 Use Of Derived Keys in Existing WS-* Specifications X.2.1 Web Services Security: UsernameToken Profile Version 1.1 This specification [LINK] describes a key derivation technique for passwords using salt and iteration count (PKCS #5 PBKDF1). It does not allow use of PBKDF2, which is the recommended method to derive keys from passwords in PKCS #5 v2.0. Initial key material cannot be referenced other than with wsu:Id. The key length will always be 160 bits. X.2.2 WS-Trust Version 1.3: Ws-Trust Version 1.3 [LINK] describes key derivation through a combination of entropies from both parties. The key is never sent on the wire. The key is never referenced directly (but further key material is derived from it). WS-Trust provides one specific method to derive keys which builds on the P_hash (P_SHA-1) function from TLS. X.2.3 WS-SecurityPolicy 1.2: WS-SecurityPolicy Version 1.2 [LINK] really only specifies whether derived keys shall be used or not but may also specify the algorithm to derive keys. The specification also identifies when derived key tokens shall appear in message headers (header layout). WS-SecurityPolicy relies on WS-SecureConversation for the definition of derived keys, key derivation methods and derived key token format. X.2.4 WS-SecureConversation 1.3: This specification [LINK] defines the wsc:DerivedKeyTokenType token type. The derived key token can be used to derive keys from any other token that contains keys. The key derivation algorithm specified builds on the P_hash (P_SHA-1) function from TLS, just as the algorithm in the Web Service Security UsernameToken Profile document. Citing from the specification: "The <wsc:DerivedKeyToken> element is used to indicate that the key for a specific reference is generated from the function. This is so that explicit security tokens, secrets, or key material need not be exchanged as often." (This latter seems dubious since the DerivedKeyToken still needs to be exchanged.) Further: "Basically, a signature or encryption references a <wsc:DerivedKeyToken> in the <wsse:Security> header that, in turn, references the <wsc:SecurityContextToken>." The derived key token does not support references using key identifiers or key names. All references MUST use an ID (to a wsu:Id attribute) or a URI reference to the <wsc:Identifier> element in the Security Context Token. X.3 Solution Requirements X.3.1 Use in existing specifications A derived key type shall be possible to use in those situations where existing specifications make use of ad-hoc derived keys or needs a derived key type The motivation for this requirement is that any XML Security definition shall be generic enough that there shall be no need to continue with "point" solutions for derived keys; i.e. it shall cover existing and foreseeable uses. X.3.2 No external dependencies A derived key type shall enable the simple use of derived keys with XML Signature or XML Encryption -using applications, and shall not require import of non-W3C developed specifications with complex security tokens. The motivation for this is that basic use of XML Signature or XML Encryption should not require use of externally defined security tokens or other security specification elements. X.3.3 Continued use of existing derivation methods An XML Security derived key type shall allow for existing methods to derive keys; i.e. it shall be possible to use already specified key derivation methods with the new derived key type. This requirement is based on the assumptions that implementations may want to continue with already chosen key derivation schemes. X.3.4 Future-proof with regards to key lengths A derived key type shall allow for arbitrary derived key lengths. X.3.5 Referential flexibility A derived key type shall allow for referencing using any referencing method in use today for other key types used in XMLDsig or XMLEnc. A derived key type shall allow for forward referencing with reference lists as recommended by WS-I BSP [Link]. X.4 Existing Specifications vs. Requirements Evaluating the existing specifications against the requirements gives the following result: UsernameToken Profile: - R1: Not met (method specified in UsernameToken profile is ad-hoc for UsernameToken specifically) - R2: Not met (method requires use of UsernameToken profile) - R3: Not met (UsernameToken profile mandates use of specified mechanism) - R4: Not met (Only accept length of 160 bits) - R5: Not met (No referencing with KeyName or KeyIdentifier and no <referenceList> element) WS-Trust: - R1: N/A (WS-Trust does not define a derived key type per se; only a method to derive keys) - R2: N/A - R3: Meets (Through use of URI to identify method and extensibility) - R4: Meets - R5: Meets (Choice of STS on how to identify key) WS-SecurityPolicy: - R1: N/A (WS-SecurityPolicy does not define a derived key type) - R2: N/A - R3: Meets (Through the use of URIs to identify key derivation methods and schema extensibility) - R4: Meets - R5: N/A WS-SecureConversation: - R1: Meets - R2: Does not meet. - R3: Meets (may use the <Properties> element to carry parameters for other key derivation methods. - R4: Meets - R5: Does not meet as referencing can only be done to a <wsse:SecurityTokenReference> X.4 Design Options X.4.1 Create a ds:DerivedKeyType type modeled after the xenc:EncryptedKeyType. In this design option, the new DerivedKeyType is modeled after the xenc:EncryptedKeyType. A *possible* outline of such a type could be: <element name="DerivedKey" type="xmlsec:DerivedKeyType"/> <complexType name="DerivedKeyType"> <sequence> <element name="KeyDerivationMethod" type="xmlsec:KeyDerivationMethodType" minOccurs="0"/> <element ref="xenc:ReferenceList" minOccurs="0"/> <element name="CarriedKeyName" type="string" minOccurs="0"/> </sequence> <attribute name="Id" type="ID" use="optional"/> <attribute name="Type" type="anyURI" use="optional"/> </complexType> <complexType name="KeyDerivationMethodType"> <sequence> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType> The proposal immediately meets requirements R2, R3 (any key derivation method may be used, including the ones specified, e.g., in WS-SecureConversation), R4 and R5. For R1 we have: Username Token Profile: As the UsernameToken Profile requires use of an existing procedure to derive keys, the proposal cannot meet formally meet requirement R1. However, since the UsernameTokenType is extensible, syntactically the requirement can be met since a <ds:DerivedKey> element could be placed in lieu of the current <salt> and <iteration> elements. WS-Trust: Use of derived keys in WS-Trust is _implicit_, since the derived key is never sent. The derived keys may be referenced by any available means in issued tokens and the requestor is only required to identify particular key derivation methods. Since URIs are used for this (the <wst:ComputedKey> element), any other key derivation method with a well-known URI may be used. Specifically, one can also envision an STS returning a proof token containing a <DerivedKey> element when there already is a shared key between the STS and a token requestor. And so, R1 is met. WS-SecurityPolicy: Not affected by a new key type. R1 is met. WS-SecureConversation: Use of derived keys in WS-SecureConversation is typically based on the establishment of a session context, from which specific keys are derived. The proposed <xmlsec:DerivedKeyType> type may be used in a similar fashion, although the interactive nature of WS-SecureConversation (exchange of Nonces, Labels) may still favor use of the existing DerivedKeyToken in this context. But as a counterexample, a party that wishes to send data authenticated with a key derived from a key established in the session, may do so using the <xmlsec:DerivedKey> element in the <ds:KeyInfo> element, and the element may refer to a SecurityContextToken that identifies the base key. This would, it seems, eliminate an absolute need for a <wsc:DerivedKeyToken> (and should be similar in nature as the "Implied Derived Key" option in WS-SecureConversation). Also, the <wsc:DerivedKeyToken> implies use of a particular key derivation algorithm (the <Label> and <Nonce> elements) although it does not require them. In summary, WS-Trust and WS-SecurityPolicy are not directly affected by this proposal. UsernameToken profile could use the proposal if the (artificial) requirement to only use the key derivation method specified in the UsernameToken Profile document was relaxed. WS-SecureConversation comes close in establishing an alternative but the specification defines a token primarily for use in interactive sessions based on a security context and which is designed for a particular key derivation method. It also seems strange to require use of such a token in more basic XMLDsig or XMLEnc situations. Finally, the proposal seems to be able to replace the DerivedKeyToken currently used in WS-SecureConversation. -- X.4.2 TBD --
Received on Tuesday, 18 November 2008 14:01:18 UTC