OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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 

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 

destination domain.pdf

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]