Use of UsernameToken Nonce and Created Without Password When UsingKey Derivation?

[Patrick Ryan <oasis@pryan.org>]

Hello,

When using UsernameToken for key derivation, it is clear that the 
password element cannot be used, but can the nonce and created elements 
still be used?  It would be nice to re-use an implementation to prevent 
replay attacks that use the nonce and created elements.

The UsernameToken Profile specification (version 1.1) says the 
following:

Lines 351-352:

    When key derivation is used the password MUST NOT be
    included in the UsernameToken.

Lines 170-174:

    If either or both of <wsse:Nonce> and <wsu:Created>
    are present they MUST be included in the digest value
    as follows:

    Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )

The intent of lines 170-174 seems to be dictating the formula, not 
necessarily that if the nonce and created elements are used then there 
must be a password element.  That's just one interpretation, of course.

There is some guidance on replay protection in the SOAP Message Security 
specification (version 1.1) in section 13.2.1:

    Digital signatures alone do not provide message
    authentication. One can record a signed message and
    resend it (a replay attack). It is strongly
    RECOMMENDED that messages include digitally signed
    elements to allow message recipients to detect replays
    of the message when the messages are exchanged via an
    open network. These can be part of the message or of
    the headers defined from other SOAP extensions. Four
    typical approaches are: Timestamp, Sequence Number,
    Expirations and Message Correlation. Signed timestamps
    MAY be used to keep track of messages (possibly by
    caching the most recent timestamp from a specific
    service) and detect replays of previous messages. It
    is RECOMMENDED that timestamps be cached for a given
    period of time, as a guideline, a value of five minutes
    can be used as a minimum to detect replays, and that
    timestamps older than that given period of time set be
    rejected in interactive scenarios.

The same replay protection could be achieved by using the UsernameToken 
salt value as the nonce and requiring a timestamp element be added to 
the security header, but it would be nice to re use the implementation 
as is.  The UsernameToken derived key is being used as an HMAC key for 
signing the SOAP request, so whatever is used for replay protection must 
be included in the signature.

Thanks,
Patrick