[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion
Jan, The situation that you mentioned is called
replay attack. I do agree with you that the EncryptedSupportingTokens without
signature protection has risk on the replay attack. However, any
authentication related attacks may lead to other pretty nasty attacks, such as
elevation of privilege attack, but this is not the point. The question is: does
our TC provide simple policy assertions that meet our policy users’ requirements
and needs? If the user only has the authentication
and confidentiality requirements, then are your suggest that the user have to
also do integrity, authorization, and non-repudiation? If the user has
problem to sign, then are you suggest that the user has to choice for no
security at all? Can we have some thing in the middle? As regarding to the replay attack, it is possible
to prevent the attack without the signature. The username can be embedded into
the message body, and the body also be encrypted with recipient’s public
cert. In this case, if the attacker just replaces the whole username token blob
will not make the replay attack. In addition, the replay attack is not just
for Username Token. The SAML Token with Bearer confirmation method will also
have vulnerability on same kind of attacks, but the WS-SP standard has the
assertion for it. The policy examples are shown on section 2.3.1.1 and 2.3.2.1
of the Example Document. This Issue PR013 has not thing to do the
strict layout format, nor the asymmetric binding rules. It also has not thing
to do with how the timestamp should be protected. As you know, there is no 100%
secure system in the world. Any vulnerability can lead to pretty nasty attacks eventually.
Therefore, I don’t think the nasty elevation of privilege attack has any
thing to do with this issue either. Instead, the Issue PR013 is: we need
EncryptedSupportingTokens assertion to protect plain text password element in
the Username Token. This is for current WSS 1.0 user which already has the encrypted
username token protection, but no key for signature. This should be a valid use
case scenario, isn’t it? It is proposed that to add EncryptedSupportingTokens
into the WS-SP spec and add the example onto Example Document for Username
Token per Issue PR012. In addition, we can document the use case and add the
security risk statement on the example. We can further suggesting to use more
secure ways to protect the Username Token, such as SignedEncryptedSupportingTokens,
where possible. Best regards, Symon Chang From: Jan Alexander
[mailto:janalex@microsoft.com] I don’t
disagree with that. However by not requiring the username supporting token to
be signed the attacker can take out the whole username token blob from the
original message and insert it into his own message and recipient of such
crafted message will not be able to tell the difference. This can lead to
pretty nasty elevation of privilege attack. From: Hal Lockhart
[mailto:hlockhar@bea.com] If the only thing you need to encrypt is
the password, it is not necessary to integrity protect it. If it is modified,
the authentication will fail. Hal From: Jan Alexander
[mailto:janalex@microsoft.com] I see. The
interesting thing to note is that the asymmetric binding does not support the
scenario described below. According to the asymmetric binding rules you are
required to sign and encrypt both the request and the reply. If you want to go
this path you’re opening yourself to a whole class of attacks based on
the fact that the message you’re sending out is not signed. I wonder if
the TC wants to promote this by explicitly creating a new supporting token type
to allow such messages to be security policy compliant. Thanks, --Jan From: Symon Chang
[mailto:sychang@bea.com] Jan, My scenario is a WSS 1.0 asymmetric
binding scenario where there is only one recipient key from the services provider.
The client does not have private key. On this scenario, the user does not want
to change from asymmetric binding to symmetric binding. The reasons are:
My motivation is to provider a simple
policy assertion for a simple cryptography problem – encrypt plain text
password using server’s certificate, instead of ask users to change their
existing WS security solution into a more complex and not interoperable
security solution. Again, this is a simple support taken
assertion for a very simple and common scenario that users want. Best regards, Symon Chang From: Jan Alexander
[mailto:janalex@microsoft.com] In your scenario the
sender either have: a) a shared symmetric key - in this case you can use the
same key to both encrypt and sign the supporting token or you can derive two
keys (recommended) one used for encryption and second one used for signature. b) a recipient public key – in this case you will use
the public key wrap a symmetric key that the sender generates which is then
used to encrypt the supporting token. Again, you can either use the same key to
sign the supporting token or you can derive two keys (recommended), one for
encryption and one for signature. In both cases you
can easily create a signature over the supporting token, therefore I
don’t understand why this support token type is needed. Can you please
clarify your motivation? Thanks, --Jan From: Greg Carpenter [mailto:gregcarp@microsoft.com]
Issue PR013 From: Symon Chang
[mailto:sychang@bea.com]
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the list when that has occurred.
Protocol: ws-sp
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/21401/ws-securitypolicy-1.2-spec-cd-01.pdf
Artifact: policy
Type: design
Title: Need EncryptedSupportingTokens assertion
Need EncryptedSupportingTokens assertion to encrypt plain text password in Username Token for authentication.
Description:
The current WS-SP spec has
SupportingTokens, SignedSupportingTokens, and SignedEncryptedSupportingTokens
assertions, but does not have EncryptedSupportingTokens assertion. Encrypted support token
without signature is a common use case, when the plain text password is used on
the Username Token for authentication, and the client does not have private key
for signature. When the server can only accept plain text password, encrypt the
password with server’s X509 certificate is a good security practice, but
existing spec does not have a simply assertion in supporting token for this
simple requirement.
Related issues:
Need policy example for encrypted username token.
Proposed Resolution:
Added new
EncryptedSupportingTokens assertion into WS-SP spec, after section 8.5. --
“SignedEncryptedSupportingTokens Assertion”. The text can be
similar to the section 8.5. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]