Re: ISSUE-48 (DerivedKeyType): No support for derived keys in XML Dsig, XML Enc [Rqmts (XML Signature and Canonicalization V Next Requirements)]

All,

To follow up on ISSUE-48 (DerivedKeyType), here's an initial analysis on 
the use of derived keys in some existing WS-* specifications, and how the 
functionality in those specifications compare to an alternative proposal 
based on a set of requirements. Comments and feedback is more than 
welcome; I may well have misrepresented or misunderstood some aspects of 
the existing specifications.

(also, apologies for the duplicate ISSUE-49; that was a mistake on my 
part. I have closed it.)

Best,
-- Magnus
--
1. Solution Requirements

Firstly, trying to identify some solution requirements:

R1: 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 the 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.

R2: A derived key type shall enable simple use of XMLDsig or XMLEnc
to exchange encrypted XML instance documents, and not require import
of non-W3C developed specifications with complex security tokens.

The motivation for this is that basic use of XMLDsig or XMLEnc should
not require use of security tokens or other security specification
elements.

R3: A 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 functions.

R4: A derived key type shall allow for arbitrary derived key lengths

R5: A derived key type shall allow for referencing using any
referencing method in use today for other key types used in XMLDsig or
XMLEnc.

R6: A derived key type shall allow for forward referencing with
reference lists as recommended by WS-I BSP.

2. Use Of Derived Keys in Existing WS Specifications

The WS-* specifications that I have looked at are:

- OASIS Web Services Security: UsernameToken Profile Version 1.1
- OASIS WS-Trust Version 1.3
- OASIS WS-SecurityPolicy Version 1.2
- OASIS WS-SecureConversation Version 1.3

Web Services Security: UsernameToken Profile Version 1.1

Describes a key derivation technique for passwords using salt and
iteration count (PKCS #5 PBKDF1). 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.

WS-Trust Version 1.3:

Ws-Trust 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 (and 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.

WS-SecurityPolicy 1.2:

WS-SecurityPolicy 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.

WS-SecureConversation 1.3:

This specification 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
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.

3. A Proposal

Create a ds:DerivedKeyType type modeled after the
xenc:EncryptedKeyType. A *possible* outline of such a type follows
here:

<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>

4. Comparison Of Proposal With Existing Specifications Using Derived
Keys

4.1 Proposal vs. Requirements

The proposal immediately meets requirements R2, R3 (any key derivation
method may be used, including the ones specified, e.g., in
WS-SecureConversation), R4, R5, R6. 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.

4.2 Existing Specifications vs. Requirements

Evaluating the existing specifications against the requirements I get
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)
- R6: Not met (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)
- R6: N/A

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
- R6: 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>
- R6: Does not meet

5. Conclusion

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.
--

Received on Thursday, 28 August 2008 15:00:36 UTC