[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss-dev] Use of UsernameToken Nonce and Created Without PasswordWhen Using Key Derivation?
My point is that there are many ways to achieve the security properties you require. Interoperability is another matter. Hal > -----Original Message----- > From: Patrick Ryan [mailto:oasis@pryan.org] > Sent: Tuesday, November 30, 2010 8:06 PM > To: Hal Lockhart > Cc: wss-dev@lists.oasis-open.org > Subject: Re: [wss-dev] Use of UsernameToken Nonce and Created Without > Password When Using Key Derivation? > > > Hello, > > Yes, the nonce will be included in the signature (the entire > UsernameToken element will be included). Neither the nonce nor the > created elements will be used as part of key derivation. The sole > purpose is to provide replay protection. > > It sounds like it would be better to introduce the timestamp > element to > the security header and use the salt element as a nonce to determine > message uniqueness. The username token elemnt (including the salt > element) and the timestamp element would both be included in > the signed > info for the signature. > > - Patrick > > On Mon, Nov 22, 2010 at 07:52:09AM -0800, Hal Lockhart wrote: > > I don't really understand you proposed implementation. Do > you plan to > > include the nonce under the signature, after the key has > been derived? > > Or do you intend to include the nonce in the key derivation > algorithm > > in some way, thus deriving a new key each time? > > > > In both cases, the key issue is interoperability. I doubt any other > > implementation will interoperate with this algorithm. The second > > approach appears to violate the WS-I Basic Security Profile 1.1 - > > R4216. I cannot see that the first approach violates any > spec, but the > > concatenation of the of the Nonce defined in the Token to the data > > under the signature is unspecified anywhere. > > > > I vaguely remember the WS-I sample applications group raising this > > point. I believe this led to section 6.4.5 of Security Challenges, > > Threats and Countermeasures Version 1.0 > > > > > http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf > > > > which says that the only interoperable way to prevent > replay is to use > > TLS. "Currently, there is no application interoperability > solution at > > the SOAP message layer." Section 5.2.5.1 of the same document > > discusses using the nonce under the signature, but notes it is not > > interoperable. > > > > As that section discusses, other approaches including using > > sufficiently fine grained timestamps to ensure uniqueness and > > arranging the SOAP messages to prevent replay are alternative > > approaches. It is also noted that to truly prevent replay with a > > nonce, it is necessary to keep all servers up to date with the > > previously used nonce values, which can be difficult if > there are many > > of them and/or they are widely distributed. > > > > Hal > > > > > -----Original Message----- > > > From: Patrick Ryan [mailto:oasis@pryan.org] > > > Sent: Thursday, November 18, 2010 1:16 PM > > > To: Hal Lockhart > > > Cc: wss-dev@lists.oasis-open.org > > > Subject: Re: [wss-dev] Use of UsernameToken Nonce and > Created Without > > > Password When Using Key Derivation? > > > > > > > > > Hello, > > > > > > My plan is to re-use the implementation for replay > protection that I > > > have when the UsernameToken has a password element. If I > > > cannot include > > > the nonce and created elements, then I have to find another > > > nonce value > > > that is included in the signature. Using just the > timestamp element > > > does not provide the level of replay protection that > included a nonce > > > does. I could use the salt value as the nonce together with the > > > timestamp element, but I was hoping to not have to change the > > > implementation, hence the question about leaving the nonce > > > and created > > > elements in place but not the password element when using key > > > derivation. > > > > > > Thanks, > > > Patrick > > > > > > On Thu, Nov 18, 2010 at 07:34:41AM -0800, Hal Lockhart wrote: > > > > 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 > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: wss-dev-unsubscribe@lists.oasis-open.org > > > > For additional commands, e-mail: > wss-dev-help@lists.oasis-open.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: wss-dev-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: wss-dev-help@lists.oasis-open.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wss-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wss-dev-help@lists.oasis-open.org > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]