Proposed Derived Key text for the Requirements document

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