Re: [ws-sx] Questions and comments.

Hi there, thanks for the detailed text.
 Is the intent that each/some of these be opened as an individual
issue? If yes which ones?

Ideally for the ones that you want to
make issues, we need them submitted in the issue template format. 

Cheers

Kelvin

WS-SX Co-chair

Davanum Srinivas <>

02/02/2006 07:12 AM

Please respond to



To

, 

cc

Subject

[ws-sx] Questions and comments.

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Team,

Here are some notes from Werner. Am posting on his behalf as his membership
status upgrade has gotten stuck somewhere

and is unable to post.

Thanks,

dims

==========================================================================

All,

here are some comments/remarks for the ws-sp spec. Most is editorial

but some are also design and clarification.

a)

In chapter 6 the spec introduces several properties to control some

behaviour. The actual XML implementation of the properties is given in

chapter 7. It is somehow difficult to link the properties defined in

chapter 6 to the actual XML tags defined in chapter 7. For example:

the [Protection Order] property can have several values. Chapter 7

then defines the real XML tags as e.g. <sp:EncryptBeforeSigning />
to

set this property. Because this property can have several values there

are several such XML tags to set this property. However, these XML

names bear no direct link to the property. Thus I would propose to use

the following notation to set a multi value property:

<sp:ProtectionOrder value="EncryptBeforeSigning" />

Such a notation would also simplify parsing because a parser has to

look for one tag name only and can use the attribute to set the

property's value.

Other properties are defined as boolean (true/false)

properties. However, the actual XML tag names to set the property

differ from the specified property name - this is somehow

confusing. Take the Signature Protection property as an example: to

set it you have to use the XML tag <sp:EncryptSignature />. Why no
use

something like:

<sp:SignatureProtection value="on" /> or

<sp:SignatureProtection value="Encrypt" /> or

just <sp:SignatureProtection />

or something similar to make clear which property is set or defined.

b)

Chapter 6.1 [Algorithm Suite]

The table at line 1280ff defines two properties [Sym KS] and [Asym

KS]. Both propteries were not shown in the bullet list starting at

line 1263. Should these two properties read [Sym Sig] and [Asym Sig]?

The table starting at line 1282 defines a property [C14n]. This

property name is the same as the abbreviation for C14n in table

starting at line 1277. This is not wrong, but choosing different names

would make it more clear.

c)

Chapter 6.3 [Protection Order] Property

In "EncryptBeforeSigning" the spec states that both keys MUST
derived

from the same source. What does this mean? Use the same certificate

for both actions (for example if a X509 cert is used). In that case

this seems an unnecessary restriction. At least WS Security does not

mandate this. Also using the same cert to encrypt and sign is not a

good security practice.

d)

Chapter 6.5 [Token protection] conflicts with chapter 8.3 and 8.4.

If the policy uses EndorsingSupportingTokens and sets [Token

Protection] then I have the same behaviour as defined for

SignedEndorsingSupportingTokens. Is that true? On the other hand if I

use a SignedEndorsingSupportingTokens and do _not_ set [Token

Protection] - what should be the result in that case?

e)

Chapter 6.7 [Security Header Layout]

Here the spec defines "LaxTimestampFirst" and "LaxTimestampLast",
both

define that a Timestamp MUST be included. On the other hand in chapter

6.2 [Timestamp] the spec defines another way to switch Timestamps

on/off. Which one rules?

f)

Chapter 7 introduces several Bindings, such as symmetric binding and

asymmetric binding.

During the asymmetric binding definition the spec introduces

RecipientToken and InitiatorToken. The description of these tokens

defines that both parties shall use the same token for encryption and

signing. This restriction is not mandated by WS Security and should

not be enforced. Also from a security point of view it should be

possible to use different tokens for encryption and signature.

g)

Include a token in message (or not?)

Using the token inclusion values (chap 5.1.1) one can specify when to

include a token. On the other hand in chap 5.3.3 X509Token Assertion

there are other way defined how to reference a X509 token. For example

if "RequireIssuerSerialReference" is set and the inclusion value
is

"always": shall the token be included in the message? Which token

shall the receipient take - the included one or the referenced?

IMHO the SecurityTokenReference (WS Security spec) in this case shall

contain the IssuerSerial reference - thus an inclsuion of the token

would be superfluous?

With respect to the WS Security specification I interpret the

inclusion value "always*" or "once" without any additional
"Require*"

assertion as "include the token as a BinarySecurityToken and refernce

it using a Reference in the SecruityTokenReference". Is this a correct

interpretation?

Also, with respect to WSS how to interpret or act on the

RequireEmbeddedRefernce assertion? WSS does not specify an "embedded"

mechanism for X509 certificates.

h)

Questions/clarifications regarding supporting tokens (maybe other

tokens such a ReceipientToken etc as well)

Can a Policy have more than one supporting token (of the same type),

e.g. multiple SupportingTokens?

Every supporting token can have more than one token assertion, e.g.

X509 token assertions. If there are more than one such token assertion

which on shall be used to sign/encrypt additional SignedParts or

EncryptedParts if some are definied?

An implementation that uses Security Policy Language has to know how

to populate the required tokens, e.g. UsernameToken or X509

tokens. Because a policy file usually contains several token

assertions there should be an attribute to identify a token. For

example if a policy requires two UsernameToken the application that

creates the message needs a way to link the different UsernameToken to

the user data records that contains username, password, etc. To do so

the application shall be able to identify the UsernameToken and use

this identifier as a link to the user data record. Simliar mechanisms

are required to locate the correct X509 certificate in a keystore, for

example. Any other ideas how to identify token in a Poliy file and

associated them with real user/alias data?

i)

Clarification for UsernameToken assertion

The UsernameToken defines additonal (optional) assertions that specify

the WSS spec version. IMHO this is not enough to fully specify a

UsernameToken. For example a UsernameToken may have a additonal

elements such as a creation time. The WSS specs do not define in any

way if such elements shall be included or not (some is recommended but

no mandated). Also the UsernameToken assertion should have a way to

define which password type to use: text or digest.

Enhancement idea:

WS SecurityPolicy profiles?

Because the sepcification as it stands allows a very large number

of combinations it is IMHO quite difficult to set up a working and

correct security policy. Would it be possible to define some sort of

"Security Policy Profiles" that define the most common usage
patterns,

for example based on WS-Security interop tests?

Regards,

Werner

==========================================================================

- --

Davanum Srinivas ()

VP/Engg, WSO2 (http://wso2.com)

Yahoo IM: dims Cell/Mobile: +1 (508) 415 7509

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFD4gUwDQylxigoT5kRAhxCAKCjjJGErW6/pOSuBMbpQcFsdcjNpwCeJzCc

A38D1NSqHYxxMHekKGSgY/c=

=fY7d

-----END PGP SIGNATURE-----