[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Proposal for a new attribute of UsernameToken
Reading Jerry's email made me think of something that happened at the interop event back in June. How are leading and trailing white space treated in the computation of the digest? It wasn't clear to me that there couldn't be a trailing or leading space in the format of the date in the <wsu:Created> element. If there was would it change the digest or not? If I'm wrong and there are schema rules for not allowing white space then I apologize for wasting the bandwidth. -Eric Oh and the interop story was that the part about KeyIdentifiers having white space and most of us not trimming it out. -----Original Message----- From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com] Sent: Tuesday, October 28, 2003 12:21 PM To: wss Subject: [wss] Proposal for a new attribute of UsernameToken At the call last week I promised to send email to the list with a proposal to add an attribute to UsernameToken. Before making the formal proposal let me explain why it is needed. The new attribute identifies a "domain" and it is included in any digest. The domain must be such that the nonce is shared between all systems in that "domain". The purpose of this new attribute is to thwart the following "replay" attack. Mal takes a message sent by Alice to Bob and diverts it to Carol. If Mal had resent the message to Bob, the nonce would have identified it as a replay. However, since Carol has never seen the particular nonce before she will accept it. For the attack to be effective the same username/password combination needs to be accepted by Carol as was accepted by Bob. In the real world this is a common situation. Of course there are other ways to thwart this attack. For example, Alice might encrypt the UsernameToken using one of Bob's certificate. But if she could do that, she wouldn't need a digest. The point of the new attribute is to thwart the attack precisely under the circumstances in which a digest is used to allow passing the UsernameToken in the clear. I attach a pdf with my proposed changes to the UsernameToken profile. I apologize that my XML skills aren't up to proposing changes to the actual schema. I recognize that many people will consider it too late to be making this change and I understand that point of view. If it prevails I hope the proposal will be incorporated into any future versions of the UsernameToken profile.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]