XML Security 1.1 Requirements and Design Considerations

This section outlines the use of derived keys with Web Services specifications related to Web Services Security [ WS-SECURITY11 ].

Web Services Security: UsernameToken Profile Version 1.1

This specification [ WSS-USERNAME11 ] 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.

3.2.2.1 WS-Trust Version 1.3:

Ws-Trust Version 1.3 [ WS-TRUST13 ] 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.

3.2.2.2 WS-SecurityPolicy 1.2:

WS-SecurityPolicy Version 1.2 [ WS-SECURITYPOLICY12 ] 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.

3.2.2.3 WS-SecureConversation 1.3:

This specification [ WS-SECURECONVERSATION13 ] 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 MUST use an ID (to a wsu:Id attribute) or a URI reference to the <wsc:Identifier> element in the Security Context Token.

3.2.3.1 Use in existing specifications (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 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.

3.2.3.2 No external dependencies (R2)

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.

3.2.3.3 Continued use of existing derivation methods (R3)

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.

3.2.3.4 Future-proof with regards to key lengths (R4)

A derived key type shall allow for arbitrary derived key lengths.

3.2.3.5 Referential flexibility (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.

A derived key type shall allow for forward referencing with reference lists as recommended by WS-I BSP [ WSI-BSP10 ].

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

Outline of possible DerivedKeyType schema definition
<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 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 requester 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 requester. 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.

3.3.2.1 Address SHA security concerns, recognize RSA de-facto use.

In order to address concerns related to potential risks associated with SHA-1 [ SHA-1-Collisions ], the following algorithm requirements that update the SHA algorithm should be met in XML Signature 1.1 and XML Encryption 1.1:

• Digest:

  SHA256 be required.

  SHA384 and SHA512 optional.

• Mac:

  HMAC-SHA256 recommended.

  HMAC-SHA384 and HMAC-SHA512 optional. (Note these are Recommended in XML Signature 1.1.)

• Signature:

  RSAwithSHA256 required.

  RSAwithSHA384, RSAwithSHA512 optional.

3.3.2.2 Revise guidance for DSAwithSHA1

In order to discourage the use of DSAwithSHA1 but to continue to enable interoperability, the following algorithm changes are requirements;

• Signature:

  Continue to require DSAwithSHA1 for signature verification, but change DSAwithSHA1 to optional (from required) for signature generation.

3.3.2.3 Add Suite B algorithm support

In order to:

1. enable long term security for digital signatures (including in commercial contexts),

2. ensure that the XML Signature standard is cryptographically secure and makes use of the best current practices for digital signature algorithms, and

3. enable use of XML Signature technology in a wide variety of commercial and government applications, including those that require Suite B

The additional algorithm requirements are as follows:

• Signature:

  Require ECDSAwithSHA256.

  ECDSAwithSHA1, ECDSAwithSHA384, ECDSAwithSHA512 optional. (Note ECDSAwithSHA1 is Discouraged in XML Signature 1.1 due to concerns with SHA-1.)

• Define ECKeyValue element to enable interoperable exchange of EC public key values in XML Signature context.

• Provide profile guidance for use of RFC 4050 [ RFC4050 ] when it continues to be used in XML Signature context but indicate preference for mechanism defined in XML Signature.

The last two requirements are discussed in more detail in the following design section.

3.3.3.1 RFC 4050 issues in XML Signature context

RFC 4050 is an informational RFC that defines a method of representing ECDSA public keys and ECC curve parameters for use with XML Signature, but it has some issues related to XML Signature:

• The RFC 4050 definition of an ECDSAKeyValue is larger than necessary.

  An ECDSAKeyValue is defined by the type ECPointType, which has subelements X and Y. X and Y are defined as FieldParamsType which is an abstract type. Separate derived types are defined for prime fields, trinomial base fields, pentanomial base fields, and odd characteristic extension fields. In order to validate against the 4050 schema, one must include the type attribute from the XML schema instance namespace. This is not a significant problem but it does make the public key larger than necessary.

• ECPointType definition is inconsistent with ANSI X9.62 and RFC 3279.

  ECPointType is reused in the definition of the ExplicitParamsType to describe the base point of a curve. The field parameters are already included in the FieldParams element. The use of the FieldParamsType in the ECPointType definition appears to be a mistake in 4050. If you look at the ASN.1 definition for ECC public keys in RFC 3279 [ RFC3279 ] , ECPoint simply references the Point to Octet String conversion function in ANSI X9.62 (section A.5.6 in the 2005 version, section 4.3.6 in the 1998 version). The conversion functions in X9.62 are not ASN.1 specific and it appears they would be implemented as part of any ECC crypto library. It appears that RFC 4050 tried to avoid using any of the conversion functions in X9.62 but somehow mixed up the definitions between a field type and a field element.

• Limitation of the decimal type in XSD

  RFC 4050 defines X and Y (at least for prime and odd characteristic extension fields) as xs:nonNegativeInteger which derives from the xs:decimal primitive type. However, XSD requires implementations to support only a maximum of 18 digits (see section 3.2.3 in [ XMLSCHEMA11-2 ] ). It is possible to create an example requiring 77 and 78 digits for X and Y respectively. This means that there is no guarantee that an RFC 4050 compliant ECDSAKeyValue element will actually validate against the RFC 4050 schema.

• Collision between the RFC 4050 DTD and the XMLDSIG DTD

  Merging the RFC 4050 DTD into the XMLDSIG DTD is a problem due to conflicting DTD definitions. In ECDSAKeyValue, Y is defined as follows:

  Example 2

  Definition of Y in ECDSAKeyValue
  <!ELEMENT Y EMPTY>
  
  
  <!
  
  
  ATTLIST
  Y
  
  
  Value
  
  
  CDATA
  
  
  #REQUIRED>
  
  

  However, DSAKeyValue defines Y as follows:

  Example 3

  Definition of Y in DSAKeyValue
  
  
  <!
  
  
  ELEMENT
  Y
  
  
  (
  
  
  #PCDATA)
  >
  
  

  ECDSAKeyValue also contains identical definition for elements SEED and P as DSAKeyValue.

  It does not seem possible to scope the definition of Y under a specific element in DTD.

3.3.3.2 Proposed Solution to RFC 4050 issues in XML Signature context

Because of these issues, a possible proposed solution is for XML Signature 1.1 to define a new ECPublicKey element in the ds namespace rather than attempt to reuse the RFC 4050 ECDSAPublicKey elements. This new element will be based on the ASN.1 definition ANSI X9.62 and RFC 3279. Changing the name of the element to ECPublicKey means it can be also used in XML Encryption to support ECDH. (Note, XML Signature 1.1 defined ECKeyValue instead).

To maximize interoperability with existing RFC 4050 implementations, we should also put a note in 1.1 to recommend implementations to support a profile of RFC 4050. The profile will support only named prime curves.