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] Correction: Issue 101 - was: Issue 98: Token Substitution - Proposed text


Title: [wss] Correction: Issue 101 - was: Issue 98: Token Substitution - Proposed text

If it is okay with Hal, I have two minor edits (see below).

 

Thanks,

Thomas.

-----Original Message-----
From
: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: Mon 6/30/2003
7:28 AM
To: wss@lists.oasis-open.org
Cc:
Subject: [wss] Correction: Issue 101 - was: Issue 98: Token Substitution - Proposed text

Sorry for the confusion: This proposal is for issue 101 not 98. I will post
text for 98, next.

At about line 1512 (security considerations) insert:

Implementers should be aware of the possibility of a token substitution
attack. In any situation where a digital signature is verified by reference
to a token provided in the message, which specifies the key, it may be
possible for an unscrupulous sender to later

-- claim that a different token, containing the same key, but different information was intended.

++ say that it intended to invoke different claims in a different token containing the same key.

An example of this would be a user who had multiple X.509 certificates
issued relating to the same key pair but with different attributes,
constraints or reliance limits. Note that the signature of the token by its
issuing authority does not prevent this attack. Nor can an authority
effectively prevent a different authority from issuing a token over the same
key if the user can prove possession of the secret.

The most straightforward counter to this attack is to insist that the

-- token (or its unique identifying data)

++ token's or claim's unique identifying data

be included under the signature of the
sender. If the nature of the application is such that the contents of the
token are irrelevant, assuming it has been issued by a trusted authority,
this attack may be ignored. However because application semantics may change
over time, best practice is to prevent this attack.

Hal


You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php



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