[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion
This is the same reason to the need of EncryptedSupportingTokens
assertion as the need of SupportingTokens assertion. The user just wants to use
WSS 1.0 encryption to protect the plain text password end-to-end. The message signature
can be provided by the transport protocol, or other message signature after the
EncryptedSupportingToken is added. Therefore, it is proposed to add the
following text to the new EncryptedSupportingTokens Assertion section as well: Encrypted supporting tokens are included in the security
header and may optionally include additional message parts to sign and/or encrypt.
The encrypted supporting tokens can
be added to any SOAP message and do not require any signature protection to be
applied to the message before they are added. More specifically there is no
requirement on “message signature” being present before the encrypted
supporting tokens are added. However it is RECOMMENDED to employ underlying
protection mechanism to ensure that the encrypted supporting tokens are
cryptographically bound to the message during the transmission. The solution of using section 4.2.2
EncryptedElement assertion to encrypted security element may have problem during
the decryption processing. For example, you don’t want the <wsse:BinarySecurityToken> block be one of encrypted element, and unable to use it at the
receiving end. If the UsernameToken is a special case of EncryptedElement that
can fulfill the need of encrypting plain-text password, then why not just simply
provide EncryptedSupportingTokens assertion? From: Jan Alexander
[mailto:janalex@microsoft.com] Yes, this needs to
be clarified more in the spec. I propose the following changes to the spec to
make this more clear: Change lines
1792-1794 as follows: Security Bindings use tokens to secure the message
exchange. The Security Binding will require one to create a signature using the
token identified in the Security Binding policy. This signature will
here-to-fore be referred to as the “message signature”. In case of Transport Binding the message is
signed outside of the message XML by the underlying transport protocol and the
signature itself is not part of the message. … Change lines 1834 –
1835 as follows: If transport security is used, only the message timestamp
(TS) is included in the Security header as illustrated below. The “message signature” is
provided by the underlying transport protocol and is not part of the message
XML. Change lines 1838 –
1839 as follows: Supporting tokens are included in the security header and
may optionally include additional message parts to sign and/or encrypt. The supporting tokens can be added to any
SOAP message and do not require any protection (signature or encryption) to be
applied to the message before they are added. More specifically there is no
requirement on “message signature” being present before the
supporting tokens are added. However it is RECOMMENDED to employ underlying
protection mechanism to ensure that the supporting tokens are cryptographically
bound to the message during the transmission. Does this help? --Jan From: Tony Gullotta
[mailto:tony.gullotta@soa.com] Good. However, its still not clear to me
then what the difference between a SupportingTokensAssertion and a
SignedSupportingTokensAssertion is. I thought if you required signing the
supporting token to "cryptographically bind" the token to the rest of
the message, you'd use SignedSupportingTokensAssertion. The
SupportingTokensAssertion did not require that. Tony From: Jan
Alexander [mailto:janalex@microsoft.com] The scenario below
is possible as the transport binding supplies the message signature. However I
agree that the spec is not clear in this regard and should be clarified to be
more explicit. The intention here is ensure that the supporting tokens are
cryptographically bound to the rest of the message. From: Tony Gullotta
[mailto:tony.gullotta@soa.com] My only issue with what your saying is "the
current spec requires you to sign the message whenever you add a supporting
token to it". We see a lot of
customer use cases where they just want to include SAML assertions or Username
tokens (maybe multiple tokens for application identity and end user identity)
but they don't want to encrypt or sign anything at the message level. They may
use SSL to protect the messages. I thought I could support those use
cases with a TransportBinding and SupportingTokensAssertions. Now I'm not so
sure. Tony From: Jan
Alexander [mailto:janalex@microsoft.com] Symon, Please see my
comments inline. Cheers, --Jan From: 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? [Jan] It is not,
because the attacker is attaching the encrypted username token to a different
message – different payload. He can essentially send any message body on
behalf of the original sender. This is called elevation of privilege. 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?
[Jan] The current
WS-SecurityPolicy spec requires you to sign the message if you are adding the
supporting tokens as per section 8, I’ve copied the text from the spec in
another thread of this discussion. The timestamp protection rules are covered
by [Timestamp] property that is orthogonal to supporting tokens. Essentially
whenever a wsu:Timestamp element is required, it is also required that the
element is covered by the message signature. 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. [Jan] See my first
comment. The attacker can substitute the body. You’re right that if you
change the application logic to require the username toke appear twice, once in
the header and once in the body and enforces that those two are the same than
you can mitigate this issue, but I would argue that you don’t need to
send the username token in the header in the first place if you already have it
in the body, right? 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. [janalex] I’m
not sure I’m following here. The SAML bearer token is added to the
message as a supporting token and thus follows the same rules as all other
supporting tokens. Your proposal for PR013 would allow this to happen, but
currently this is not possible. 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? [janalex] My
argument is that the current spec requires you to sign the message whenever you
add a supporting token to it (see section 8). In other words you cannot use
supporting tokens without having some key to sign the message with. And if you
are able to sign the message you’re can very easily add username token to
the signature so I don’t see a need for this assertion. 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, 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: 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, 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:
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]