Password Derived Keys support in Metro

This feature is about allowing a UsernameToken as a Protection Token under Symmetric Binding .Also we can use this feature as an Initiator Token under Asymmetric Binding.

The Password associated with a Username Token will be used to derive a new Secret Key for the purpose of Integrity and confidentiality .

We require two additional elements to derive the Secret Key from a password.

They are Salt and Iteration. These are not kept secret and must be sent with a UsernameToken. When this key derivation is used the password must not be included in the username token

The folowing example illustrates the use of this key derivation .Also it illustrates the form of UsernameToken which goes on the wire.

<wsse: UsernameToken wsse:Id = ".....">

                 <wsse:Username>Suresh</wsse:Username>

                <wsse11:Salt>Absds/FHfgh/swderfa==</wsse:Salt>

                <wsse11:Iteration>1500</wsse:Iteration>

</wsse: UsernameToken>

Derivation of Secret Key:

A) We generate a 16 byte Random array which will be called Salt.

we set the first byte of the Salt ,thus generated to 01 , if the Key is to be used for MAC or to 02 if the Key is to be used for Encyption

B) The Password and Salt are concatenated in the that order and that value is hashed using SHA1 algorithm

C) The value thus obtained is again hashed using SHA1 and this process is repeated until the total no of hash operations equals to Iteration count

Mathematicaly ,     K1 = SHA1(Password + Salt);

                             K2 = SHA1(K1);

                            ....

                            ....

                             Kn = SHA1(Kn-1); n = iteration count.

D) The Key thus derived is of 160bit value, may be used as a MAC or as a Symmetric key for encryption. When used as a MAC we use the 160 bits and when used for encryption we use only higher order 128 bits( lower order 32 bits will be truncated)

E) If the Iteration value is not specified a default value of atleast 1000 should be used for Iteration.

How it works? The receiving side will use the password (that it already knows) and Salt and Iteration(received from the request) to derive the same key again.After deriving the key the receiver verifies the Signature and decrypts the message.

So using this feature , with just UsernameToken we can Sign and Encrypt the messages with out requiring any other tokens(like X509, Kerboros...)

where we can use this Token? This Token can be used

  i) As an InitiatorToken/InitiatorEncryptionToken of an AsymmetricBinding ,

 ii) As a  ProtectionToken /SignatureToken of a SymmetricBinding and

iii) As an EndorsingSupportingToken/SignedEndorsingEncryptedSupportingToken/

SignedEndorsingSupportingToken/EndorsingEncryptedSupportingToken

Note:The use of this token as ProtectionToken/InitiatorToken/SignatureToken would require WSS 1.1 assertion to be enabled to make use of EncryptedKeySHA1 reference mechanism.

A Sample WSDL policy looks like this:

<wsp:Policy wsu:Id="NewWebServicePortBindingPolicy">
        <wsp:ExactlyOne>
            <wsp:All>
                <wsam:Addressing wsp:Optional="false"/>
                <sp:SymmetricBinding>
                    <wsp:Policy>
                        <sp:ProtectionToken>
                            <wsp:Policy>
                                <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
                                     <wsp:Policy>                                          
                                           <sp:WssUsernameToken10/>
                                     </wsp:Policy>
                                </sp:UsernameToken>
                            </wsp:Policy>
                        </sp:ProtectionToken>
                        <sp:Layout>
                            <wsp:Policy>
                                <sp:Strict/>
                            </wsp:Policy>
                        </sp:Layout>
                        <sp:IncludeTimestamp/>                   
                        <sp:OnlySignEntireHeadersAndBody/>
                        <sp:AlgorithmSuite>
                            <wsp:Policy>
                                <sp:Basic128/>
                            </wsp:Policy>
                        </sp:AlgorithmSuite>
                    </wsp:Policy>
                </sp:SymmetricBinding>
                <sp:Wss11>
                    <wsp:Policy>
                        <sp:MustSupportRefIssuerSerial/>
                        <sp:MustSupportRefThumbprint/>
                        <sp:MustSupportRefEncryptedKey/>
                    </wsp:Policy>
                </sp:Wss11>
                <sc:ValidatorConfiguration xmlns:sc="http://schemas.sun.com/2006/03/wss/server">
                                <sc:Validator name="usernameValidator" classname="ws.SampleDerivedKeyPasswordValidator" />
                </sc:ValidatorConfiguration>               
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>

You can see one  Username Validator config  in the above policy. A sample UsernameValidator is here

Some sample implementations which use the above PDK concept are uploaded here

Sample with service and client

App2

App2Client

Please note that to run above samples you have to use your own UsernameHandler (currently my username and password are there)

Download link: This feature works with latest Metro builds(24/03/2009). You can download the latest nightly builds from the following link.

Download link for Metro 2.0

https://metro.dev.java.net/servlets/ProjectDocumentList?expandFolder=7638&folderID=10314

References:http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html

Comments:

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 01, 2009 at 09:46 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 01, 2009 at 09:54 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 01, 2009 at 09:57 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 01, 2009 at 10:02 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 01, 2009 at 10:06 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 01, 2009 at 10:09 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 01, 2009 at 10:17 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 01, 2009 at 10:21 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 01, 2009 at 10:31 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 03, 2009 at 07:21 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on June 03, 2009 at 07:27 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on July 07, 2009 at 10:34 AM MVT #

[Trackback] Security Token Configuration in Metro

Posted by Kumar Jayanti's Blog on July 08, 2009 at 05:45 AM MVT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Suresh Mandalapu

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today