Encryption algorithm and policy

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Alex Shirshov - 01 Oct 2004 08:26 GMT

Hello, All!

I wonder why so smart policy infrastructure in WSE 2.0 doesn't support
wssp:Algorithm element of the wssp:Confidentiality assertion. I mean it
doesn't when the encription algorithm differ from default
(http://www.w3.org/2001/04/xmlenc#aes128-cbc as i investigate). For example,
I change the default algo at client on 3des as following
[code]
Dim utokman As Tokens.UsernameTokenManager = _

CType(Tokens.SecurityTokenManager.GetSecurityTokenManagerByTokenType(WSTrust
.TokenTypes.UsernameToken), _
Tokens.UsernameTokenManager)

utokman.DefaultKeyAlgorithm = "TripleDES"
[/code]

The server policy looks like
[policy]
<wssp:Confidentiality wsp:Usage="wsp:Required">
<wssp:Algorithm Type="wssp:AlgEncryption"
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:KeyInfo>
<wssp:SecurityToken>

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-user
name-token-profile-1.0#UsernameToken</wssp:TokenType>
<wssp:Claims>
<wssp:UsePassword wsp:Usage="wsp:Required"
Type="wssp:PasswordDigest"/>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:KeyInfo>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Confidentiality>
[/policy]

I run the app and got
[server error]
An unsupported signature or encryption algorithm was used
[/server error]

To get this work I MUST explicitly set the desired algo as default for
UserTokenMan
[server]
Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
Dim utokman As Tokens.UsernameTokenManager = _

CType(Tokens.SecurityTokenManager.GetSecurityTokenManagerByTokenType(WSTrust
.TokenTypes.UsernameToken), _
Tokens.UsernameTokenManager)

utokman.DefaultKeyAlgorithm = "TripleDES"
End Sub
[/server]

The question is: Is this a bug or just a feature? And if it is a feature
what is the reasons of it?
Should I go to feedback center to report a bug or I could make a suggestion?

With best regards, Alex Shirshov.

Reply to this Message

Hervey Wilson [MSFT] - 01 Oct 2004 09:19 GMT

> Hello, All!
>
[quoted text clipped - 3 lines]
> (http://www.w3.org/2001/04/xmlenc#aes128-cbc as i investigate). For example,
> I change the default algo at client on 3des as following

SNIP

> The question is: Is this a bug or just a feature? And if it is a feature
> what is the reasons of it?
> Should I go to feedback center to report a bug or I could make a suggestion?
> :)

The rationale for the design is that, without a means to negotiate
policy, the server typically will define the algorithm that must be used
to communicate with it. This algorithm can be set in policy and in
configuration. The ability to switch algorithms at the client
programmatically through the token manager gives the client flexibility
to talk to servers with different requirements.

We considered that this was a reasonable solution given the lack of a
mechanism for both sides to negotiate to a common set, but would be
happy to learn more about concrete scenarios that need the server to be
switchable.

Signature

This posting is provided "AS IS", with no warranties, and confers no rights.

Reply to this Message

Alex Shirshov - 01 Oct 2004 12:14 GMT

Hello, Hervey!
You wrote on Fri, 01 Oct 2004 01:19:09 -0700:

[Sorry, skipped]

HWM> The rationale for the design is that, without a means to negotiate
HWM> policy, the server typically will define the algorithm that must be
HWM> used to communicate with it.

I can send the policy by email or through another webservice. Anyway, I
agree, that client MUST know about the encryption method.

HWM> This algorithm can be set in policy and in configuration.

I don't know how to set algorithm for UserTokenManager in configuration.
Using policy it will be only declaration and the server, as I pointed in the
previous post, MUST set it programmatically. At best (not programmatically
in the case of X509TokenMan) we should set it two times: in policy and in
configuration.

HWM> The ability to switch algorithms at the client programmatically
HWM> through the token manager gives the client flexibility to talk to
HWM> servers with different requirements.

Totally agree.

HWM> We considered that this was a reasonable solution given the lack of a
HWM> mechanism for both sides to negotiate to a common set, but would be
HWM> happy to learn more about concrete scenarios that need the server to
HWM> be switchable.

I'm not clearly understand what is "to be switchable" for server. I expect
that declaring the encryption algorithm in the policy wse will
[i]automatically[/i] use it for appropriate client messages as it do in case
of signing, for instance. But it is not enough to set encryption method in
policy! I must also change the defaultKey for the TokenMan. So why? Why I
have to set the algo in two different places (in case of UserTokenMan
programmatically) instead of just define it in the policy?
Is there any technical reason to not use (or ignore) policy statement
duaring decription of the client messages?

With best regards, Alex Shirshov.

Reply to this Message

Hervey Wilson [MSFT] - 06 Oct 2004 07:54 GMT

> Hello, Hervey!
> You wrote on Fri, 01 Oct 2004 01:19:09 -0700:

SNIP

> I'm not clearly understand what is "to be switchable" for server.

By this I mean that a service can accept more than 1 value for the
algorithm.

> I expect
> that declaring the encryption algorithm in the policy wse will
[quoted text clipped - 5 lines]
> Is there any technical reason to not use (or ignore) policy statement
> duaring decription of the client messages?

There's no technical reason this cannot be done (i.e. it's not
impossible), it's simply a limitation in the current implementation -
specifically it's a limitation in the policy engine and the current
SecurityToken framework. I fully expect that this will change for WSE3.

Signature

This posting is provided "AS IS", with no warranties, and confers no rights.

Reply to this Message

Encryption algorithm and policy

Free Magazines