RE: [wss-dev] Use of UsernameToken Nonce and Created Without PasswordWhen Using Key Derivation?

[Hal Lockhart <hal.lockhart@oracle.com>]

It is not clear what you plan to do with the nonce and created when using a derived key.

The assumption made when the spec was written was that after a key has been derived, it will be used to construct signatures and encrypt data. When signing data, a timestamp element should included under the signature to ensure freshness, as discussed in the WSS Core spec. The nonce is not needed, because the signature is over the actual message data.

Hal

> -----Original Message-----
> From: Patrick Ryan [mailto:oasis@pryan.org]
> Sent: Saturday, November 13, 2010 12:58 AM
> To: wss-dev@lists.oasis-open.org
> Subject: [wss-dev] Use of UsernameToken Nonce and Created Without
> Password When Using Key Derivation?
> 
> 
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wss-dev-help@lists.oasis-open.org
> 
>