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

Magnus

Thank you for writing this proposal - I've added it to the agenda for  
11 November. My apologies for the delay in getting it on the agenda,  
but we've had a number of joint meetings lately.

I should point out that although it is useful to determine how  
previously written specifications could take advantage of this  
proposal, it is not required (or always likely) for them to be  
modified at this time. Thus in my (non-chair) opinion,  not meeting R1  
for some of these should not be an issue unless it implies a lack of  
capability going forward.

regards, Frederick

Frederick Hirsch
Nokia



On Aug 28, 2008, at 10:58 AM, ext Magnus Nyström wrote:

>
> 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 Friday, 7 November 2008 22:06:31 UTC