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