[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Use of UsernameToken Nonce and Created Without Password When UsingKey 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]